Hallo Dominik,
deine Lösung und die von Hardware-Entwickler liegen von der Berechnung her nicht weit auseinander.
Bei dir: Prescale 256, Timer läuft nach 250 Ticks über, Zähler läuft bis 250 == 256 * 250 * 250 = 16M
Bei ihm: Prescale 1024, Timer matched nach 125 Ticks, Zähler läuft bis 125 == 1024 * 125 * 125 =16M
Seine ISR wird nur halb so oft pro Sekunde aufgerufen, verbraucht also weniger Prozessorzeit.
Wichtiger ist der Unterschied mit CTC Mode und Timer vorladen. Bei deiner Art bist du in Teilen von der Ausführungszeit der ISR abhängig. Speziell bei kleinen Prescale Werten ergeben sich dadurch signifikante Abweichungen.
Anders der CTC Mode. Der Timer läuft praktisch komplett in HW, inklusive Zurücksetzen. In der ISR änderst du nichts am Timer.
Leider wird deine Art in allen Tutorials, Foren und auch in der Bascomhilfe immer als erstes gezeigt und scheint auch besser verständlich zu sein. Aber ich würde dir raten, grundsätzlich darauf zu verzichten.
Der CTC Modus funktioniert in Bascom so:
Config Timer2 = Timer, Prescale = 1024, Clear_Timer=1, Compare = Toggle
Compare2 = 124 '125 Ticks, weil der Timer bei 0 anfängt (deshalb 125 - 1), du kannst auch OCR2 = 124 schreiben
On Compare2 Timer_Isr
Enable Compare2
Allerdings glaube ich nicht, dass dadurch mehrere Sekunden pro Minute zu erklären sind.
Zeig doch mal dein ganzes Programm.
Ich denke das Problem sind hier die Begrifflichkeiten.Was bedeutet ctc bei orc2 = 125-1?
Und was genau meinst du mit timer2_comp interrupt?
CTC bedeutet Clear Timer at Comparematch und heisst, wenn das entsprechende TCNT Register den Wert des Comparematchregisters erreicht wird es in der Hardware sofort wieder auf 0 gesetzt. Beispiel Comp 2 Register hat den Wert 127, TCNT2 erreicht 127 und wird sofort auf 0 gesetzt.
zu 2. So ein Timer kann nicht nur bei einem Überlauf einen Interrupt produzieren, sondern auch wenn das TCNT Register den Wert eines Comparematchregisters erreicht. Dadurch hat man bei der Wahl der Prescaler mehr Möglichkeiten den gewünschten Teilerfaktor zu erreichen.
Grundsätzlich bevorzuge ich große Prescaler, weil sich damit normalerweise eher seltener Interruptaufrufe ergeben.
Wenn dein 16 Bit Timer frei läuft kannst Du sogar dort noch deine Uhr mit einbauen.
Du gibst dort den Comparematch Interrupt frei und zählst zum Comparematchregister innerhalb dieses Interrupts den Wert für den nächsten Zeitabschnitt dazu.
Dadurch kommt es immer wieder zu festen Zyklen zu einem Comparematch Interrupt.
Zusätzlich würde ich Dir empfehlen eine zusätzliche Vergleichs- " Uhr " wie eine Real Time Clock ( RTC ) oder DCF 77 als Vergleich zu benutzen, weil sonst Deine Uhr nach längerer Zeit falsch gehen wird. Die Zeitbasis ist ja vom Controllerquarz abhängig, der auch nich zu 100% genau ist.
Hallo,
erstml danke für die zahlreichen Antworten.
bessere Grade den Code aus, doch leider nimmt er die Zeile:
On Compare2 ISR_von_timer2 nicht an (error 117)
Kann ich anstelle von compare2 auch timer2 schreiben?
Gruß
Dominik
Geändert von Dominik009 (20.12.2013 um 12:39 Uhr)
Jo, ich hab nen mega32 und Bascom 1.11.9.0
Du weißt schon, dass aktuell die Version 2.0.7.6 raus ist, also 3 Generationen weiter.
Ich habe den Code jetzt trotz des angeblichen Fehlers geflasht. Nun macht mein Controller (oder ein anderes Bauteil) extrem merkwürdige Geräusche (so eine Art brummen).
Werde gleich den stark vereinfachten Code mal versuchen hier ins Board zu bekommen.
Viele grüße
Dominik
Edit: Oh, das wusste ich nicht. Sollte ich die. Erosion updaten?
Bisher hatte i h nämlich nie Probleme mit der Version
Lesezeichen