www.mikrocontroller.net

Forum: Compiler & IDEs ATtiny26, Timer0 und Timer1 kommen sich in die Quere


Autor: Paul H. (powl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich beobachte gerade bei meiner Discolicht-Binäruhr-Kombination einen 
interessanten Konflikt zwischen den Timern 0 und 1.

Bevor ich hier den ganzen Code poste möchte ich mein Problem erstmal so 
schildern:

Timer0 läuft mit Vorteiler 8. Parallel dazu läuft der Timer1 mit 
Vorteiler 64. Zuerst wird Timer0 gestartet und dann gleich Timer1, sie 
dürften also nahezu synchron zueinander laufen.

Der Timer0 OVF ISR habe ich das Attribut ISR_NOBLOCK gegeben, so dass 
sie die ISRs des Timer1 nicht behindert. Hier wird ein bisschen 
Rechenzeit für das LED-Lauflicht verwendet.

Die Timer1 OVF ISR setzt PORT und DDR fürs Charlieplexing, danach wird 
sie durch ein sei(); entschärft und führt dann weitere unwichtige 
Codeteile aus. D.h. sie braucht auf jedenfall einige Takte am Anfang für 
sich und gibt andere Interrupts erst danach wieder frei.

Die Timer1 COMPA ISR löscht PORT und DDR fürs Charlieplexing wodurch ich 
die LEDs dort dimmen kann. In der niedrigsten Stufe bleiben zwischen der 
OVF-ISR und der COMPA-ISR gerademal 64 Takte Zeit, aber das ist soweit 
schaffbar. Wenn ich Timer0 deaktiviert habe, klappt alles.

Nun das komische: Sobald ich Timer0 aktiviere fangen die Uhr-LEDs bei 
runterdimmen in der dunkelsten Stufe nochmal an aufzublitzen.

Hier mal eine Art Timeline: (+ = OVF-ISR, # = COMP-ISR)
Timer1: +#--- ----- ----- ----- ----- ----- ----- ----- +#---
Timer0: +---- +---- +---- +---- +---- +---- +---- +---- +----

Ich kann mir das nun nicht richtig erklären. Dass die LEDs aufblitzen 
deutet darauf hin, dass die COMPA-ISR (in der die LEDs ja abgeschaltet 
werden) übersprungen wird und der Timer eine Runde voll durchläuft. Das 
kann aber eignetlich nicht sein, denn das Flag ist ja gesetzt. Timer1 
hat eine höhere Priorität als Timer0 und in der Timer0 OVF-ISR dauert es 
bis zum erneuten Setzen des I-Flags eigentlich nur 4 Takte. Ohne mir 
wirklich ernsthafte Gedanken über das Timing zu machen habe ich einfach 
mal versucht den Timer0 mit dem Wert 127 vorzuladen wodurch er nun nicht 
mehr synchron mit dem Timer1 läuft sondern um die hälfte versetzt. Nun 
flackert nix mehr und alles klappt.

Timer1: +#--- ----- ----- ----- ----- ----- ----- ----- +#---
Timer0: --+-- --+-- --+-- --+-- --+-- --+-- --+-- --+-- --+--

Das ist zwar schön und gut, aber ich würde gerne nachvollziehen können 
warum ;-)

lg PoWl

Autor: Timmo H. (masterfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke es hängt damit zusammen, dass alleine durch den Aufruf der ISR 
ja zig Takte benötigt werden (der Interrupt, der Sprung in die ISR, die 
register die in der ISR gesichert werden, die Register die am Ende der 
ISR wieder zurückgeschrieben werden).
Ich würde das ganze jetzt erstmal step-by-step durchdebuggen und gucken 
wo er sich da verhaspelt.

Autor: Paul H. (powl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du meinst durch den aufruf der Timer0 OVF-ISR? Nein, das habe ich im 
C-Code so implementiert:
ISR(TIMER0_OVF0_vect, ISR_NOBLOCK)
{
...

d.h. die Interrupts werden sofort nach dem Ansprung der ISR wieder 
aktiviert. In Assembler sieht das dann so aus:
00000464 <__vector_6>:
 464:  78 94         sei
 466:  1f 92         push  r1
 468:  0f 92         push  r0
 46a:  0f b6         in  r0, 0x3f  ; 63
 46c:  0f 92         push  r0
 46e:  11 24         eor  r1, r1
 470:  2f 93         push  r18
...

gleich am Anfang der ISR steht somit das sei wodurch hier höchstens 
ein paar Takte verloren gehen (4? 5?).

Es ist noch zu beachten, dass der Timer0 vor Timer1 gestartet wird, d.h. 
er läuft ein paar Takte vor (wenn ich TCNT0 nicht vorlade) und die 
Timer0 OVF-ISR wird vor der Timer1 OVF-ISR ausgeführt. Das erklärt aber 
immernoch nicht ganz, was da passiert. Ich zeig euch mal die relevanten 
Codeteile der Timer1-ISRs:

Hier wird PORTA und DDRA fürs Charlieplexing gesetzt und OCR1A mit dem 
neuen Wert geladen (in diesem Fall müsste das ja dann 1 sein, also 
blieben 64 Takte bis zur Ausführung). Wenn OCR1A rechtzeitig neu gesetzt 
wird und die OVF-ISR einfach nur zu lange dauert müsste das COMPA 
Interrupt Flag trotzdem gesetzt werden und die ISR gleich danach 
ausgeführt werden. Ich probier da wohl gleich mal etwa rum.
ISR(TIMER1_OVF1_vect)
{
  if(OCRvalue > 0)
  {
    PORTA = port | 0b10000000;
    DDRA = phase_DDR[phase] | port;

    OCR1A = OCRvalue;
  }

  sei();

  [...]
}

ISR(TIMER1_CMPA_vect)
{
  PORTA = 0b10000000;
}

Autor: Paul H. (powl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, das viele blabla hätte ich mir sparen können. Es war so wie ich mir 
gedacht habe ;-) Der Timer0-OVF hat den Aufruf der Timer1-OVR wohl 
gerade ein paar Takte blockiert, so dass OCR1A zu spät neu gesetzt wurde 
und der Timer1 einmal die Runde gedreht hat.

So klappt es nun auch ohne Vorladen des TCNT0 registerts. 
Vorsichtshalber habe ich nun mal noch den Start des Timer0 hinter den 
des Timer1 gelegt.
ISR(TIMER1_OVF1_vect)
{
  // OCR1A gleich am Anfang neu besetzen, damit die CMPA-ISR nicht übersprungen wird
  OCR1A = OCRvalue;

  if(OCRvalue > 0)
  {
    PORTA = port | 0b10000000;
    DDRA = phase_DDR[phase] | port;
  }

  sei();
  [...]
}

Danke für die Hilfe!
Heiei, das ist echt kompliziert. Noch vor ein paar Wochen wär ich an 
sowas verzweifelt!

lg PoWl

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Heiei, das ist echt kompliziert.

Naja, du machst es vielleicht nur unnötig kompliziert. Sind 
unterbrechbare ISR's usw. wirklich erforderlich?

Zum Beispiel in einer deiner letzten Anfragen mit Code:

Beitrag "In ISR wird pointer nicht gescheit gesetzt?"

Da wird die aktuelle Szene in der ISR gewechselt. Damit fängst du dir 
einen Haufen Probleme ein, angefangen von den atomaren Zugriffen. Zwar 
kannts du das im Hauptptogramm mit cli()/sei()-Klammerungen lösen, daber 
dann ist so ziemlich die ganze Hauptschleife ununterbrechbar.

Ich vermute, eine ISR der Form
ISR(TIMER1_OVF1_vect)
{
 szenenwechsel = TRUE;
}

mit Abfrage des Flags und Durchführung des Szenewechsels im 
Hauptprogramm, an einer genau definierten Stelle, erfüllt die 
Anforderungen ans Programm genauso, und löst alle Probleme mit atomaren 
Zugriffen und sämtliche Timingprobleme.

Oliver

Autor: Paul H. (powl)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hm, entweder ich deaktiviere den Timer0 ganz oder ich mache die ISR 
unterbrechbar, denn sonst behindert sie den Timer1 und dessen Timing ist 
ziemlich knapp kalkuliert.

In der Timer0 OVF-ISR wird nur der nächste Schritt der Lichtszene 
ausgeführt. In der Timer1 OVF-ISR wird der Szenenwechsel durchgeführt. 
Beide sind jedoch zu diesem Punkt unterbrechbar. Praktisch wird es nicht 
passieren, dass der Timer0 OVF genau in den schreib-befehl des 
Szenenadresszeigers fällt, aber theoretisch könnte das natürlich 
passieren. Das ließe sich wiederum entweder ganz einfach durch ein 
cli(); und sei(); vor und nach dem Schreibbefehl lösen oder indem ich 
sowohl die Routine für den Szenenwechsel als auch die für den nächsten 
Szenenschritt in das Hauptprogramm packe.

Praktisch ist es eigentlich egal wie ich es mache. Ich war eben etwas 
auf den Lerneffekt aus und wollte mal gucken wie es mit den beiden 
Timern läuft. Wenn ich alles in den mainloop packe und sequentiell 
ausführe, müsste ich nur ein paar "Vorteiler" für die ADC-Messungen, 
Abfrage des Tasters (Prellen) usw.. einbauen, damit diese nur alle paar 
ms ausgeführt werden, macht eigentlich auch nix. Je nachdem wie viel 
Code darin durch die ganzen ifs ausgeführt wird läuft der loop mal 
schneller, mal langsamer, verglichen zu den 100µs Wartezeit am 
Schleifenende ist das jedoch an den LEDs in der Praxis nicht 
festzustellen. Es funktioniert also beides und du hast natürlich recht 
damit, dass es somit komplizierter wird. Ich dachte auch schon daran den 
Szenenwechsel durch den Timer0 nur zu triggern.

Im Anhang mal meinen Code, falls noch grobe Fahrlässigkeiten entdeckt 
werden kann ich die gerne ändern. Danke, dass ihr euch mit meinem 
Anliegen beschäftigt habt!

lg PoWl

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.