RN-Control und AVR STudio/GCC probleme

[lineage]

das kann ich nachher mal testen (hab noch einen m32 da)

[lineage]

So habs probiert. ...original C-File, original Header und das auf einen neuen m32 (Fuses hab ich vom Alten kopiert)
SPIEN
Bootsz size=1024 address 3C00
Bootrst
sut_CKsel Ext.Crystal High Freq. 16K ck+64ms

in der config hab ich 16000000 Hz eingestellt (16 Millionen /16MHz)

probleme bestehen wie gehabt.

[Hubert.G]

Also da ist doch ein Wurm im Programm. Kann allerdings nur das Piepen testen.
In der rncontrol.h habe ich bei sound das _delay_ms durch waitms ersetzt und in der Funktion waitms den Wert __c = 400 eingegeben, anstelle 4000.
Kann nicht sagen wie sich das auf das Lauflicht auswirkt.

[BurningWave]

Setze am besten mal F_CPU von Hand, damit auch wirklich sichergestellt wird, dass im Programm mit 16000000 Hz gearbeitet wird. Achte auch auf Warnungen wie "warning: F_CPU redefined" die ein Hinweis darauf sein können, dass im Quelltext F_CPU an irgendeiner Stelle auf einen falschen Wert (mit dem dann weitergearbeitet wird) gesetzt wird.

(Falls du es noch nicht weißt, dass Makro F_CPU wird von z.B. util\delay.h zur Zeitberechnung verwendet. Setzen mit #define F_CPU 16000000ul)

mfg

[Hubert.G]

Die F_CPU mit 16000000 stimmt, sonst würde der UART nicht funktionieren.

[lineage]

habe zuerst F_CPU getestet...ohne erfolg

danach habe ich das _delay_ms durch waitms ersetzt....das hat zumindest einiges an verbesserung gebracht (Der Controller ist jetzt fast so flott wie mit dem Bascom Compilat)
vorrübergehend werde ich mir mit Bascom etwas aushelfen um wenigstens meine ersten schritte mit dem Atmel zu machen.
ich denke das problem liegt in der erzeugung der verzögerungen (_delay_ms) und da werde ich mich demnächst mit befassen

vielen dank an alle für die hilfe.
Gruß
Lineage

[michl78]

Hallo miteinander, ich habe auch das Problem, dass das Programm zu langsam abläuft. RN-Control 1.4 16 MHz, fertig aufgebaut gekauft von robotikhardware.de . Die Fuses müssten daher doch auf den Quarz mit 16 MHz passend voreingestellt sein, oder? _delay_ms durch waitms ersetzen sowie in der Funktion waitms den Wert __c = 400 anpassen hat geholfen, aber ich würde gerne verstehen, warum das so ist. Wenn das Programm für einen 16MHz-Quarz geschrieben ist, warum muss ich dann diese Werte anpassen? RS232-Ausgabe in Hyperterminal funktioniert, ich benutze Eclipse mit AVRDude.

[BurningWave]

Eiegntlich müsste _delay_ms bei korrekt gesetzten Fuses und F_CPU funktionieren (hat es bei mir zumindest immer getan).

Die Fuses müssten daher doch auf den Quarz mit 16 MHz passend voreingestellt sein, oder?

Bei neuen AVRs ist standartmäßig ein interner Takt von 4 MHz eingestellt (sofern sie nicht schon programmiert wurden).

mfg

[michl78]

Ja, kommt mir eben deswegen ja auch komisch vor. Laut AVRDude sind meine Fuses Low EF , High D9. Hab mir mal über http://www.engbedded.com/fusecalc/ die Sache angeschaut mit diesen Werten, scheint doch eigentlich zu passen so. Weiss aber nicht, ob ich das alles richtig deute. In dem Beispielcode ( http://www.rn-wissen.de/index.php/RN...oprogramm_in_C ) ist der Wert F_CPU nicht defined. Hab das mal mit #define F_CPU 16000000UL vor dem include <util/delay.h> gemacht, zeigt aber keine Änderung. Kann jemand, der mit Fuses Erfahrung hat, mir mal sagen, ob der Proz mit Quarz 16 MHz getaktet ist anhand obiger Fuse-Werte. Und ob das JTAG so steht, daß mir alle Ports zur Verfügung stehen (hab kein JTAG Debugger oder sowas). Danke im Voraus...

[oberallgeier]

... Hab mir mal über http://www.engbedded.com/fusecalc/ die Sache angeschaut mit diesen Werten, scheint doch eigentlich zu passen so ...
... Kann jemand, der mit Fuses Erfahrung hat ...

Diese Frage verstehe ich jetzt nicht. Im Fusecalculator kannst Du Dir die Fuses auf Low EF , High D9 einstellen, [Apply Values] drücken - und dann anschauen. Der Calculator sagt doch ALLES ! (Anmerkung: manchmal lohnt es, eine Seite runterzuscrollen).