Sekundentakt mit Timer erzeugen

Klaus Gast 18.05.2009 16:36 #1267497

Lesenswert?

•

Hallo!


Ich hab gerade Probleme mit meinem Sekundentakt. Ich hab eine 
Interruptroutine, die eigentlich mit genau 1Hz aufgerufen werden sollte. 
Zum Vergleich, hab ich mittels der _delay_ms Funktion ein Blinken einer 
anderen LED in die Hauptschleife geschrieben.

#include <avr/io.h>
#include <avr/interrupt.h>
#define F_CPU 1000000UL
#include <util/delay.h>
volatile int second = 0;
void init_timers()
  //Timer 1 auf Sekunden-Takt einstellen
        // 1Mhz/(64*15625) = 1 Hz 
  OCR1A= 15625;
  TIMSK |= (1<<OCIE1A);
  TCCR1A = 0x00;
  TCCR1B |= (1<<WGM12)|(1<<CS11)|(1<<CS10); // CTC mode; 64 prescale
ISR(TIMER1_COMPA_vect)
  //toggle led
  if( PORTB & (1<<LED_SEC) )
    LED_SEC_ON;
    LED_SEC_OFF;
  second++;
int main()
  init_timers();
  sei();
  while (1)
    LED_MESSURE_ON
    _delay_ms(1000);
    LED_MESSURE_OFF
    _delay_ms(1000);



Theoretisch sollten die LEDs doch fast gleichschnell blinken. (In der 
Hauptschleife ganz minimal langsamer).

Aber leider blinkt die timergesteuerte LED in einer Minute ca. 29 mal. 
Die LED in der Hauptschleife blinkt (ausreichend genau) 30 mal.

Könnte mit jemand ein Fehler im Code zeigen, oder bestätigen, dass der 
so richtig ist? Der ORC1A Wert is doch richtig berechnet, oder? Danke 
schonmal!

P.S.: Der Einfluss der Ungenauigkeit des internen RC-Oszillators sollte 
sich ja auch beide LEDs gleich auswirken und somit keinen Einfluss auf 
die unterschiedliche Blinkgeschwindigkeit haben.

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Oliver Gast 18.05.2009 16:50 #1267517

Lesenswert?

•

▲
▼

>Könnte mit jemand ein Fehler im Code zeigen,

Wenn das der ganze Code wäre, vielleicht. Bei deinem gezeigten Code 
dürfte gar nichts blinken, da kein Pin von PORTB jemals auf Ausgang 
geschaltet wird.

>Der ORC1A Wert is doch richtig berechnet, oder?

1Mhz/(64*15625) = 1 Hz ist richtig.

>Aber leider blinkt die timergesteuerte LED in einer Minute ca. 29 mal.
>Die LED in der Hauptschleife blinkt (ausreichend genau) 30 mal.

Es wäre interessant zu wissen, ob die Timer-LED tatsächlich langsamer 
blinkt, oder ob (z.B. zu Beginn) einmal Blinken fehlt.

Oliver

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Karl H. (kbuchegg) 18.05.2009 16:58 #1267525

Lesenswert?

•

▲
▼

>   // 1Mhz/(64*15625) = 1 Hz
>   OCR1A= 15625;

Das müsste IMHO 15624 sein.
Der Timer soll 15625 unterschiedliche Zustaände einnehmen. Auch 0 ist 
ein Zustand. D.h. wenn der Timer bis 15624 gezählt hat, hat er mit dem 
nächsten Tick bereits bereits 15625 Timerticks abgezählt.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Oliver Gast 18.05.2009 18:41 #1267649

Lesenswert?

•

▲
▼

>In CTC mode the counter is cleared to zero when
>the counter value (TCNT1) matches either the OCR1A (WGM13:0 = 4) or the ICR1 
>(WGM13:0 = 12).

IMHO sind 15625 und 0 ein und derselbe Zustand - daher passt 15625.

Oliver

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan E. (sternst) 18.05.2009 18:45 #1267657

Lesenswert?

•

▲
▼

Oliver schrieb:

> IMHO sind 15625 und 0 ein und derselbe Zustand - daher passt 15625.

Nein, sind es nicht. Das Datenblatt ist hier ein wenig missverständlich. 
Das Rücksetzen auf Null erfolgt erst im nächsten Takt, nicht 
gleichzeitig mit dem Compare-Match.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Johann L. (gjlayde) 18.05.2009 22:05 #1267940

Lesenswert?

•

▲
▼

Da kannst einfach den Compiler (bzw. Präprozessor) die richtigen Werte 
ausrechnen und auch warnen lassen, falls der Timer ungenau arbeiten 
sollte:

#include <avr/io.h>
#define F_CPU 1000000
// IRQs pro Sekunde
#define IRQS 1
#define PRESCALE 64
#if F_CPU / PRESCALE / IRQS -1 < 1
# warning Timer1 arbeitet falsch
#if F_CPU / PRESCALE / IRQS -1 > 0xffff
# warning Timer1 arbeitet falsch
#if (F_CPU % (PRESCALE * IRQS)) != 0
#   warning Timer1 arbeitet ungenau
void timer1_init (void)
    // CTC-Mode und PRESCALE=64
    TCCR1A = 0;
    TCCR1B = (1 << WGM12) | (1 << CS11) | (1 << CS10);
    // OutputCompare für gewünschte Timer-Frequenz
    OCR1A = (unsigned short) ((unsigned long) F_CPU / PRESCALE / IRQS -1);
    // OutputCompare-Interrupt A für Timer 1
    TIMSK |= (1 << OCIE1A);

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Andreas V. (tico) 19.05.2009 01:03 #1268114

Lesenswert?

•

▲
▼

Karl heinz Buchegger schrieb:
>>   // 1Mhz/(64*15625) = 1 Hz
>>   OCR1A= 15625;
>
> Das müsste IMHO 15624 sein.
> Der Timer soll 15625 unterschiedliche Zustaände einnehmen. Auch 0 ist
> ein Zustand. D.h. wenn der Timer bis 15624 gezählt hat, hat er mit dem
> nächsten Tick bereits bereits 15625 Timerticks abgezählt.

Das ist korrekt.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Klaus Gast 19.05.2009 11:04 #1268385

Lesenswert?

•

▲
▼

so, ich habs nun nochmal nachgemessen, indem ich im Interrupt bis 15 
Minuten gezählt hab, und mit ner Stopuhr verglichen hab. Der Takt stimmt 
tatsächlich.

Die Variante mit _delay_ms(1000) is diejenige, die falsch läuft. Das es 
nicht so genau ist, ist ja klar, aber eine so große Abweichung hätte ich 
nicht erwartet. Möglicherweise die verringerte Auflösung aufgrund der 
großen Zeit? Obwohl in der Doku eigentlich 10 ms Auflösung steht. Und 
die zusätzlichen Befehle zwischen den Delays sollten ja auch keinen so 
großen Einfluss haben. Naja, aber das is jetzt ja auch gar nicht mehr 
wichtig :)


Und danke für den Hinweis, dass ich den Wert eins zu hoch gewählt hatte 
:)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Simon K. (simon) 19.05.2009 12:28 #1268479

Lesenswert?

•

▲
▼

Nenenene, Moment mal!

Richtig ist natürlich 15625-1=15624!

Mega16 Datenblatt (10/06) Seite 77:

$f_{OCn}=\frac{f_{clk\_I/O}}{2*N*(1+OCRn)}$


Das gilt zwar für den OC-Output. Aber da die Frequenz durch zwei 
Timerüberläufe und einem Toggle gemacht wird gilt:

$f_{OC\_Int}=\frac{f_{clk\_I/O}}{N*(1+OCRn)}$


macht bei 15625: 0,99993600409573787277614232689108 Hz.
=> Richtig ist also 15624 als OCR Wert.

PS: Nur um das noch mal zu bestätigen. ;)

Ich würde in dem Falle die Makros von Georg bevorzugen. Mache ich in 
meinen Programmen eigentlich auch so. Da braucht man dann nicht den 
Taschenrechner vorkramen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

icke Gast 19.05.2009 13:01 #1268515

Lesenswert?

•

▲
▼

Klaus schrieb:
>Obwohl in der Doku eigentlich 10 ms Auflösung steht.

10 * 60 = 600

logisch oder

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Klaus Gast 19.05.2009 13:03 #1268520

Lesenswert?

•

▲
▼

> Klaus schrieb:
>>Obwohl in der Doku eigentlich 10 ms Auflösung steht.
>
> 10 * 60 = 600
>
> logisch oder

Bitte, was?^^ Logisch ja, aber auf was für eine Frage war das jetzt die 
Antwort? ;)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Karl H. (kbuchegg) 19.05.2009 13:51 #1268576

Lesenswert?

•

▲
▼

icke schrieb:
> Klaus schrieb:
>>Obwohl in der Doku eigentlich 10 ms Auflösung steht.
>
> 10 * 60 = 600
>
> logisch oder

Schon.
Aber eine Sekunde besteht aus 100 Stück 10ms Abschnitten.
Also nicht 10*60 sondern 10*100 = 1000

Daher ist
  _delay_ms( 1000 )
schon korrekt.

Die Abweichung wird wahrscheinlich 2 Ursachen haben.
* _delay_ms wird auch nicht auf die µs genau die Zeit einhalten
* du machst ja neben dem delay auch noch sonst was drumherum.

Ich denke mal, ersteres wird den größten Einfluss haben. _delay_ms wird 
nicht jeden Taktzyklus zählen, wenn es die Warteschelifen aufsetzt.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

VonNixNeAhnung Gast 20.05.2009 14:12 #1269928

Lesenswert?

•

▲
▼

Wurde noch nicht erwähnt, vielleicht könnte das hier 
Beitrag "Die genaue Sekunde / RTC" interessant sein.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Sekundentakt mit Timer erzeugen

Antwort schreiben