Vielleicht kann mir jemand helfen, im AVR-Studio 4 erhalte ich bei beim schreiben des WDTCSR-Registers immer eine Fehlermeldung: ldi R16, (1<<WDE) | (1<<WDP2) | (1<<WDP0) out WDTCSR, r16 error: Operand 1 out of range: 0x60 Aus dem Datenblatt S.54 habe ich dieses Beispiel. Bernhard
Angehängte Dateien:
-
Zwischenablage01.jpg
96 KB
Habe es mal getestet, gleicher Fehler. Laut AVR-Instruction-Set arbeitet der Port-Befehl OUT mit den Registern R0-R31 und den Portadressen 0-63 bzw. 0x00-0x3F. Aber WDTCSR=0x60, also als Portadresse zu groß. Atmel-doc8059.pdf für ATmega1284(P), Seite 6, Kap.4. About Code Examples Bei I/O-Registern (Ports) im erweiterten I/O-Speicherbereich müssen die Befehle IN, OUT, SBIS, SBIC, CBI und SBI durch Befehle ersetzt werden, die den Zugriff auf erweiterten Speicher erlauben: typischerweise sind dies LDS und STS in Kombination mit SBRS, SBRC, SBR und CBR.
:
Bearbeitet durch User
Bernhard S. schrieb: > Aus dem Datenblatt S.54 habe ich dieses Beispiel. Leider gibt es hin und wieder kleine Copy & Paste-Schlampereien. Dies ist eine davon. Das haben sie wohl vom Atmega8 abgeschrieben. mfg.
Danke Rainer, LDS und STS ermöglichen den Zugriff auf WDTCSR. ldi R16, (1<<WDE) | (1<<WDP2) | (1<<WDP0) STS WDTCSR, r16 ------------------------------------------------------------------- Hier mal ein kleines Beispiel für eine WDR Initialisierung, nach 2s beißt der Watchdog zu. Interessant finde ich, wenn WDIE=1 gesetzt wird, dann erfogt bei einer Zeitübeschreitung, zuerst ein Interrupt-Aufruf, hier könnte man z.B. die Ursache der Zeitüberschreitung darstellen und anschließend, bei einer weiteren Zeitübeschreitung, ein Neustart des Systems. WDR_INITIALISIERUNG: WDR LDS R16, WDTCSR ori R16, (1<<WDCE) | (1<<WDE) STS WDTCSR, R16 ldi R16, (1<<WDE)| (0<<WDIE)|(0<<WDP3)| (1<<WDP2) | (1<<WDP1) | (1<<WDP0) STS WDTCSR, R16 ret Bernhard
:
Bearbeitet durch User
Na, dann funktioniert es ja. Auf dem STK500 mit nur 8 LEDs wird es aber schwierig, wenn die LEDs die normalen Ausgaben, die Position im Menü und dann auch noch Fehlermeldungen anzeigen sollen ;) Thomas Eckmann schrieb: > Leider gibt es hin und wieder kleine Copy & Paste-Schlampereien. Dies > ist eine davon. > > Das haben sie wohl vom Atmega8 abgeschrieben. oder ATmega32/162/8515, ATtiny13/2313 uvm., da ist WDTCR=0x21. Bei z.B. ATmega328P gilt wieder die Regel wie bei ATmega1284P, siehe gemeinsames Datenblatt ATmega48A/48PA/88A/88PA/168A/168PA/328/328P. Darin steht auf S.52 ein Code-Beispiel mit LDS und STS für WDTCSR. Allerdings wird im C-Code-Beispiel am Schluß WDTCSR=0x00 gesetzt. Wie das jetzt? Da müßte doch beim Compilieren ein Fehler wegen Redefinition von WDTCSR kommen.
Bernhard S. schrieb: > Interessant finde ich, wenn WDIE=1 gesetzt wird, dann erfogt bei einer > Zeitübeschreitung, zuerst ein Interrupt-Aufruf, hier könnte man z.B. die > Ursache der Zeitüberschreitung darstellen und anschließend, bei einer > weiteren Zeitübeschreitung, ein Neustart des Systems. Der Interrupt dient dazu, noch irgendwelche Daten ins EEPROM zu retten oder der Peripherie nocht etwas mitzuteilen. Hängt das Programm allerdings in einer ISR, wird der Interrupt nicht bedient. Der Reset findet aber ab auf jeden Fall statt. Ein wdt_reset ist jetzt unwirksam. Eine 2. Chance gibt es nicht. Rainer V. schrieb: > oder ATmega32/162/8515, ATtiny13/2313 uvm., da ist WDTCR=0x21. Bei z.B. > ATmega328P gilt wieder die Regel wie bei ATmega1284P, siehe gemeinsames > Datenblatt ATmega48A/48PA/88A/88PA/168A/168PA/328/328P. Darin steht auf > S.52 ein Code-Beispiel mit LDS und STS für WDTCSR. Allerdings wird im > C-Code-Beispiel am Schluß WDTCSR=0x00 gesetzt. Wie das jetzt? Da müßte > doch beim Compilieren ein Fehler wegen Redefinition von WDTCSR kommen. Das ist keine Definition, sondern ins WDTSCR wird Ox00 geschrieben. Im Zusammenhang der 0x21 handelt es sich um die Definition von WDTCR für den Präprozessor. mfg.
:
Bearbeitet durch User
>wenn die LEDs die normalen Ausgaben, die Position im Menü und >dann auch noch Fehlermeldungen anzeigen sollen ;) Manchmal genügt eine einzige LED, um wenigsten den Fehler einzugrenzen. >Hängt das Programm allerdings in einer ISR, wird der Interrupt nicht >bedient. Seitdem man arbeitet mit verschachtelten Interrupts
Bernhard S. schrieb: > Seitdem man arbeitet mit verschachtelten Interrupts Die aber nicht zum Repertoire eines AVR gehören. mfg.
>> Seitdem man arbeitet mit verschachtelten Interrupts >Die aber nicht zum Repertoire eines AVR gehören. Was hältst Du von dieser Variante: Kurz nach einem Interruptaufruf, werden die Interrupts wieder freigegeben, ein weiterer interrupt (z.B. ein TIMER) könnte diese Interruptroutine (INT0) unterbrechen und ersteinmal abgearbeitet werden? INT0: sei ' Interrupts wieder freigeben ... ... reti
:
Bearbeitet durch User
Bernhard S. schrieb: > Was hältst Du von dieser Variante: Gar nichts. So ein Hackermist ist meistens der Grund dafür, dass man überhaupt einen Watchdog braucht. Die Abarbeitung eines Interrupts beim AVR geht sehr schnell. Wer dazu noch verschachtelte Interrupts braucht, macht grundsätzlich etwas falsch. mfg.
:
Bearbeitet durch User
>> Was hältst Du von dieser Variante: >Gar nichts. Aber dennoch möglich ^^ >macht grundsätzlich etwas falsch. Kann, muss aber nicht sein.
:
Bearbeitet durch User
Bernhard S. schrieb: > Aber dennoch möglich ^^ Ja und? Es ist auch möglich, sich einen Atmega aufs Knie zu nageln. Bernhard S. schrieb: > INT0: > sei ' Interrupts wieder freigeben Ausserdem ist diese Methode vom Timing her schlecht. Dafür gibt es das Attribut ISR_NOBLOCK. Damit erfolgt die Freigabe mit dem ersten Befehl in der ISR, noch vor der evtl. push- und Initialisierungs-Orgie. Bernhard S. schrieb: > Kann, muss aber nicht sein. Jetzt tu mal nicht so, als wärst hier der grosse Crack: Bernhard S. schrieb: > im AVR-Studio 4 erhalte ich bei beim schreiben des WDTCSR-Registers > immer eine Fehlermeldung: mfg.
:
Bearbeitet durch User
"ISR_NOBLOCK" scheint es aber beim ATmega1284p nicht zu geben, zumindest finde ich es im Datenblatt nicht?
Bernhard S. schrieb: > "ISR_NOBLOCK" scheint es aber beim ATmega1284p nicht zu geben, > zumindest > finde ich es im Datenblatt nicht? Herrje, das steht doch nicht im Datenblatt. http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html#ga44569cb914d2aaf8fbb436f8f7c4ca68 mfg.
Rainer V. schrieb: > wird im C-Code-Beispiel am Schluß WDTCSR=0x00 gesetzt. Thomas Eckmann schrieb: > Das ist keine Definition, sondern ins WDTSCR wird Ox00 geschrieben. Sorry! Habe es jetzt gesehen, keine Direktive, sondern normaler Code. > Es ist auch möglich, sich einen Atmega aufs Knie zu nageln. So einen F**k macht doch keine S**. Im TV war aber mal ein armer Russe, der hat mittels heissem Lötkolben ein Geschwür aus seinem Knie entfernt. Übrigends: Irgendwo war zu lesen, daß bei gleichzeitig auftretenden Interrupts sich der AVR diese merkt und dann in Reihenfolge der Priorität abarbeitet. Wo merkt er sich diese denn? Und werden ältere Interrupts bei Bedarf verworfen oder gibt es irgendwann einen Overflow?
Hi
>Wo merkt er sich diese denn?
In den Interrupt-Flags der entsprechenden IO-Module.
Ein Interrpt-Flag kann sich genau ein Interruptereignis merken.
Deswegen macht man Interruptroutinen so kurz wie möglich.
Allerdings unterschätzen Anfänger die Abarbeitungsgeschwindgkeiten meist
gewaltig. Und dann kommen sie auf solche Ideen, wie z.B. verschachtelte
Interrupts.
MfG Spess
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.