Hi! Bisher habe ich den Timer 2 asynchrone im CTC-Mode mit einem 100KHz-Quarz an TOSC1/2 als Zeitquelle in Millisekunden benutzt, OC-Wert = 100000/1000 = 100 bzw. 100 - 1 = 99 weil der OC-Int. erst nach dem Vergleich eins später ausgeführt wird, war auf jeden Fall exakt. Habe das jetzt auf den Timer Overflow 2 umgestellt. Um den Timer 2 richtig zu setzen müßte eigentlich folgende Berechnung stimmen: TCNT2 = 256 - ( 100000 / 1000) = 156. Also genau 100 Timertakte bis zum Overflow. Leider geht das dann um ca. 2% zu langsamm und ich muß mit TCNT2 = 256 - ( 100000 / 1000 - 3) = 159 korrigieren. Das wären dann 97 statt 100 Quarz-Takte bis zum Overflow aber seltsammerweise stimmt das dann. Woran kann das liegen, das im Timer-Overflow es 3 Takte weniger sein müssen als im OC-CTC-Mode? Es läuft zwar jetzt wieder exakt aber es wurmt mich schon irgend wie. MfG Andi
Theorie und Praxis:
>>>Um den Timer 2 richtig zu setzen müßte eigentlich folgende
Berechnung
stimmen:
Bis du den Timerwert neu setzen kannst, vergehen ein paar
CPU-MainClock-Takte. 4-6 um zum Vektor zu springen, dann zur ISR und
wenn du C benutzt, dann nochmal 10 Takte, bis ein paar Register gepusht
sind (falls du nicht grad einen auf nackt spielst).
Du musst dir im ASM-Listing anschauen, wie lange er braucht, bis deine
Setzen-Anweisung ausgeführt wird, und das abziehen. Wird aber ungenau,
weil die CPU-Takte wohl nicht mit dem T2-Takt korrigiert werden
können.. bleib bei CTC, wenns genau sein soll.
Ob das 99 statt 100 richtig ist, weis ich grad nicht.. keine Lust
nachzudenken :)
Hallo Andi... Weil der Timer während der Interrupt-Response-Time weitergelaufen ist. Versuche es doch mal mit Einlesen des akt. Timerwertes und Aufaddieren des zu setzenden Wertes. Dann passt das wieder und unterschiedliche Interrupt-Response-Times werden ausgeglichen. Du musst jetzt nur noch die Takte zum Einlesen, addieren und schreiben berücksichtigen. Bit- & Bytebruch... ...HanneS...
Der Timer2 läuft zwar mit einem Prescaler von 1, aber ein Takt des 100KHz-Quarzes sind 160 CPU-Takte (16MHz ext.). Da ist doch eigentlich genügend Zeit, um am Anfang der TOIE2-ISR den TCNT2 neu zu setzen. Oder setzt es etwa den Prescaler des Timer 2 beim setzen von TCNT2 zurück? Die ISR gibt zwar wegen anderer, Zeitkritischere, ISRs Interupts wieder frei, aber erst nach dem setzen von TCNT2. Ausserdem ist der Timer Overflow in der "Rangliste" der Timer ganz oben (der Erste) wegen der Priorität, deswegen verwundert mich das ganze. Ansonsten versuche ich es gerne mit Addition des errechneten Timerwertes zum aktuellen Stand bzw. ich lasse mir das erst mal auf dem LCD ausgeben, bin schon gespannt, ob es da wirklich solche Verzögerungen gibt. Andere Möglichkeit wäre natürlich den Timer durchlaufen zu lassen und alles im OC-Mode zu machen, ohne CTC, und den OC-Wert einfach zu addieren für den nächsten Interrupt. Da aber 2 verschiedene Dinge verschieden schnell passieren müssen, das eine mit 1KHz und das andere mit 2KHz, benötigt das dann wieder entsprechendes Softwarehandling. Das uns der Kater bald verlasse... Andi
...das mit dem Precaler oben war glaube ich quatsch da sowieso auf 1. MfG Andi
Habe jetzt in der TOIE2-ISR nach dem ersten Register-Push mit 2 Befehlen (IN und STS) den Timer-Stand kopiert um den dann vom Main-Programm ausgeben zu lassen. Als Timer-Wert, bei dem der Timer Overflow ausgelöst wird, wird immer 1 angezeigt, nicht 0. So wird wahrschienlich der Overflow-Interrupt erst ausgelöst, nach dem um 1 weitergeschaltet wurde, genau so wie bei einem Output Compare. Also müßte dann diese Formel eigentlich richtig sein: TCNT2 = 256 - ( 100000 / 1000 - 1 ) = 157 Das wären dann 99 Takte bis zum Overflow und dann einer zum 100sten was ja dann passen würde. Wenn ich das mit AVR-Studio debugge, löst AVR-Studio allerdings bei TCNT2 = 0 sofort einen Overflow aus. Was stimmt jetzt und warum fehlen mir bei einem "-1" immer noch 2 Takte wenn ich mich logisch fehrhalte? MfG Andi
...kleine Korrektur. Bei einem Prescaler von 8 wird von TCNT2 0 ausgelesen. Möglich, das der Prescaler noch eine Rolle spielt. Der Overflow-Interrupt wird wohl erst nach dem eigentlich Overflow von 255 auf 0 UND dem togglen des Prescaler ausgelöst. Bei einem Prescaler von 1 ist TCNT2 dann schon auf 1 weitergezählt, logisch, während bei 8 in TCNT2 noch 0 ist. Aber so langsamm kommt Licht ins Dunkle! Auszug aus dem PDF zum Mega16: "When writing to one of the registers TCNT2, OCR2, or TCCR2, the value is transferred to a temporary register, and latched after two positive edges on TOSC1." Mit anderen Worten, der geschriebene Wert für TCNT2, OCR2 und TCCR2 wird gepuffert und erst nach 2 positiven Flanken an TOSC1 in die Register geschrieben. Das gilt wohl nur im Asynchronen Betrieb des Timer2. Summasumarum ist der Abgleichwert dann -1 wegen Prescaler = 1 + -2 wegen 2 Takte verzögertes schreiben in TCNT2. Wie der Zufall will, ergibt das dann folgende Formel: TCNT2 = 256 - ( 100000 / 1000 - 3) = 159 MfG Andi
Jetzt noch mal zusammenfassend! Betreibt man den Timer2 im asynchronen Modus und ohne Prescaler bzw. Prescaler = 1 dann gilt das obige mit dem -3 zum ermittelten Timer-Wert. Ab einem Prescaler von 8 und höher natürlich nicht da ja diese 3 Verzögerungen des externen Taktes zwischen 2 Timer-Werten passieren. MfG Andi
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.