Timer funktioniert nicht 16-Bit CTC

Wo ist sei(); ?

MFG
Falk

sorry hab ich hier nicht gepostet, ist aber drin!

Hast du interrupt.h includet?
Woher weist du eigentlich, das der Interrupt nicht
angesprungen wird?
Warum sind s und min nicht volatile? Die werden ja doch wahrscheinlich
von der Hauptschleife her ausgelesen?
usw. usw.

Poste doch bitte das komplette Programm!
Dann  brauchen wir nicht jedes Fitzelchen Code nachzufragen.
Nimm einfach dein *.c und hänge es als Attachment an.
Das ist erstens für dich viel einfacher und zweitens kann
dann keine Information fehlen.

der Code ist hier drin:
http://www.mikrocontroller.net/attachment/highlight/30489

Ich habe den Code auch mal auf einem Mega32 getestet mit 16 Mhz:

1

int main(void) {

2

3

  //CTC Modus & Vorteiler 8

4

  TCCR1B |= (1<<CS11)|(1<<WGM12);

5

  //Interrupt bei Compare Match

6

  TIMSK = (1<<OCIE1A);

7

  //Compare Wert setzen

8

  OCR1A = 20000-1;

9

10

  sei();

und eine Sekunde ist nach ca. 8 Sekunden um. Also es funktioniert doch. 
Nur zu langsam.

Dann läuft Dein Controller vermutlich nicht mit 7,... MHz sondern mit 1 
MHz. Dann musst Du vermutlich die Fusebits entsprechend ändern, dass 
der Controller auch weiß, dass er mit dem Quarz laufen soll und nicht 
mit dem internen RC-Oszillator.

Also der Mega162 läuft ganz sicher mit Ext. Oszi! Beim Mega32 bin ich 
mir auch ziemlich sicher! (Alle CKSEL gesetzt)!

oder habe ich mich nur verrechnet?

Beim 16 Mhz:

160000/16000000=0.01
   |
160000/8=20000

Sind ne ms nicht 10^-3 Sekunden?

Stimmt ihr habt natürlich recht blöder Fehler vielen Dank!

Marian wrote:
> Nein, ne Millisekunde sind 10e-4 Sekunden, also 1/1000. 1e-3 ist auch
> eine Millisekunde^^ :)
Doch, eine Millisekunde sind 10^-3 Sekunden, und das sind 0,001 
(Grundschule: Man nehme eine 1 und schiebe das Komma um 3 Stellen nach 
links...). 10^-4 (oder 1e-4 wie manche es lieber schreiben) sind 
logischerweise 0,1 ms...

EDIT: OK, 10e-4 sind natürlich 1e-3... Das ist natürlich ein völliges 
Durcheinander.

daraus resultiert aber ein neues Problem!...ich komme für eine ms nicht
mehr auf einen ganzzahligen ctc wert.

Florentin S. wrote:
> daraus resultiert aber ein neues Problem!...ich komme für eine ms nicht
> mehr auf einen ganzzahligen ctc wert.

Jetzt bist du reif für das hier:
http://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC

könnte ich es auch nicht so machen:

7372800/1000/64=115.2

Also sind es alle 5ms eine zuenig...also zähle ich alle 5 eine dazu.

ne es ist eine zu viel

bei den 36864 sind da die -1 schon inbegriffen?

Gibt es überhaupt einen triftigen Grund für die Verwendung eines 
Baudratenquarzes? Das beschriebene Problem ist nämlich der gewaltige 
Nachteil von solchen Quarzen. Die haben nunmal Frequenzen, die ein 
Vielfaches von 300 Hz sind. Und alles mit ner "3" drin ist in solchen 
Fällen etwas problematisch. Wenn es irgendwie geht, nimm lieber nen 
Standardquarz (z.B. 8 MHz, damit lassen sich sehr schön ms-Takte 
erzeugen).

Naja ist halt ne rein serielle Anwendung.

Florentin S. wrote:
> Naja ist halt ne rein serielle Anwendung.
Das sagt erstmal gar nichts. Viele übliche Baudraten lassen sich auch 
mit Standardquarzen mit ausreichender bis sehr guter Genauigkeit 
erzeugen. Baudratenquarze brauchts eigentlich nur dann, wenn man 
entweder auf irgendeine bestimmte Baudrate festgelegt ist, die mit 
Standardquarzen nicht generierbar ist oder wenn man flexibel zwischen 
allen üblichen Baudraten wählen können will. Teilnehmer A und Teilnehmer 
B müssen sich nur auf eine Baudrate einigen. Und wenn beide Teilnehmer 
µCs sind, dann braucht man sich nicht mal an die Standard-Baudraten (mit 
300Hz * 2^n) zu halten...

na die Echtzeit Uhr ist für einen Timeout zuständig und ersetzt die 
Softwarewaits, so das Programm nebenbei noch andere Dinge tun kann.