Warum will mein Timer2 nicht beim ATMEGA128

Feb 27, 2007 14 Replies

Hallo,



ich kriege mit einer einfachen Routine die Krise, mein Timer2 will einfach nicht loslaufen. externer Quarz ist dran, Prescaler ist konfiguriert.



countTimer2 bleibt aber immer 0, wo ist der Haken?


----------------------------------------------------------------------------



-- volatile uint8_t countTimer2;



// ISR zum auffangen der Interrupts: (alle 10ms) SIGNAL(SIG_OUTPUT_COMPARE2) { countTimer2++; }



void main(void){



TCCR2 = (1


Moin!

Hm, kann auf den ersten Blick nix erkennen, aber...

Woran erkennst Du das? In Deinem Beispiel wird countTimer2 nirgends abgefragt und an irgendwelchen Pins wackelst Du auch nicht.

Fehlersuche:

- Setz mal toggle on compare match und PB7:OC2 als Ausgang und schau obs da wackelt.

- Schau in der Hauptschleife nach, ob das OCF2 im TIFR gesetzt aber nicht abgeholt wird.

- Wackel in der Interruptroutine an Pins.

Gruß, Michael.

Es fehlt ein sei();

mfg Jan

"Brennecke Werner"

cli(); //Interrupts ausschalten

sei(); //Interrupts aktivieren

"Brennecke Werner"

Wo deklarierst du countTimer2 eigentlich? Doch wohl nicht innerhalb der Timerroutine? Ich hoffe du hast dann wenigstens ein static davorstehen

SCNR,

Markus

"Brennecke Werner"

static uint8_t countTimer2;

Hi!

Ups, das hab ich übersehen. Ich habs grade mal in den AVR Sim kopiert, geht problemlos. Eine Idee hätte ich noch:

Probier mal ein while(1) asm("nop");

Irgendwer hat mir mal erzählt, dass der AVR nicht in den Interrupt springt wenn zwischen zwei jmps (oder 2* dem gleichen) nicht noch ein Befehl kommt. Kann aber auch absoluter Blödsinn sein (habs noch nie beobachtet oder Probleme damit gehabt...

@Werner: Wie haste eigentlich kontrolliert welchen Wert countTimer2 hat?

mfg Jan

Brennecke Werner schrieb:

Ändert zwar nichts am Verhalten, aber das sollte besser als ISR(TIMER2_COMP_vect) geschrieben werden.

"Markus Schaub"

while(1) { //Hier in Sleepmodus setzen so dass Interrupts aufwecken set_sleep_mode(SLEEP_MODE_IDLE); sleep_mode(); }

halte ich für eleganter.

Hallo,

Jetzt gehts, der Compiler hat das scheinbar wirklich "wegoptimiert" :-)

Das gefällt mir, ist schon übernommen.

danke für die Hilfe, Ihr habt ein Pils gut wenn Ihr mal in der Gegend seit :-)

Gruß Werner

"Brennecke Werner"

Falls du indirect GCC benutzt rate ich dir grundsätzlich dazu nur die erste oder zweite Optimierungsstufe zu verwenden. Die dritte ist grundsätzlich unsicher. Steht auch so in der Hilfe.

Markus Schaub schrieb:

Ja. Was soll er daran wegoptimieren? Eine Endlosschleife ist eine Endlosschleife, die *darf* er nicht wegwerfen.

cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)

"maqqusz" schrieb:

Humbug. Oder auch FUD, wie man's nimmt. Ich frage mich, in welcher ,,Hilfe'' das stehen soll.

Die dritte Stufe optimiert halt auf Geschwindigkeit, von der Warte her ist sie es meist bei einem AVR nicht Wert (zumal kürzerer Code beim AVR auch sehr oft schnellerer Code ist). Daher dürfte -Os die beliebteste Optimierungsstufe sein. Aber ich habe noch keinen korrekten C-Code gesehen, der beim AVR-GCC zwar mit -Os funktioniert aber mit -O3 nicht mehr (von pathologischen Fällen wie durch -O3 übergelaufenen ROM oder Timing-Problemen natürlich abgesehen).

cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)

Joerg Wunsch schrieb:

Die Option O3 dürfte dann auch mit dem Function-Inlining und dem Loop-Unrolling anfangen, was für einen Controller mit 128kb Flash doch nicht ganz so geeignet ist.

Mfg Thomas Pototschnig

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required