Output Compare Match Interrupt, Richtung des Counters

Gast #4320083
Lesenswert?
• ▲
▼
OC schrieb:

> Hallo, kann man beim ATMega 168 im "Output Compare Match Interrupt"
> (TIMER1_COMPA_vect) feststellen ob der Counter gerade am hoch oder
> runterzählen war?

Nur, indem du den Overflow-Interrupt zu Hilfe nimmst. Die Frage ist nur: 
wozu soll Ganze eigentlich nützlich sein?

Oder anders ausgedrückt: mit einiger Wahrscheinlichkeit versuchst du da 
ein Problem zu lösen, was eigentlich garnicht existiert...
Gast #4320327
Lesenswert?
• ▲
▼
Hallo OC (Gast),

Up- und Down-Counting gibts beim Counter1 des ATMega168
(glaube ich) nur in den PWM-Modes.

Die PWM-Hardware im ATMega168 ist extra darauf ausgelegt, den
Ablauf des µC-Programms nicht zu stören. Dank "doble buffered"
Counter-Registern kann man den PWM-Duty-Cycle ändern, ohne sich
um den Hardware-Ablauf zu kümmern.

Ansonsten - siehe im aktuellen Datenblatt:
Figure 16-8. Phase correct PWM mode, timing diagram.
und
Figure 16-9. Phase and frequency correct PWM mode, timing diagram.

Dort wird gezeigt, welche Interrupts du nutzen kannst, um die
aktuelle Zählrichtung bereitzustellen:

Nutze den "Interrupt on Bottom" um eine globale Variable,
(nennen wir sie COUNTER1_UP) auf TRUE und den "Interrupt on TOP"
um sie auf FALSE zu setzen.

Diese beiden Interrupt-Routinen kosten natürlich jeweils
ca. 20...30 Takte, was bei höheren PWM-Frequenzen einiges
an zeitlicher Auslastung bedeutet und die Reaktionszeiten
für andere Interrupt-Anforderungen verlängern kann.
Gast #4320360
Lesenswert?
• ▲
▼
Derzeit mache ich das genau so. (Variable im TIMER1_OVF_vect)
Leider klappt das bei hohen PWM-Frequenzen und kurzer Impulsbreite nicht 
zuverlässig. Hätte ja sein können, dass es da ein Register für gibt, 
welches ich übersehen habe. Schade, scheint nicht so...
Gast #4321577
Lesenswert?
• ▲
▼
Hallo OC (Gast),

mir ist noch was Schnelleres eingefallen. Das dürfte nur etwa
5 zusätzliche Takte kosten (oder 9, wenn Tmp0 (R16) extra hierfür
noch gesichert und wiederhergestellt werden muss).

Funktioniert aber nur, wenn TIMER1_OVF keinen Interrupt auslöst!

Alternativ könnte man es mit der "on TOP"-Bedingung machen...

1
    in Tmp0, TIFR1            ; Flagregister -> Register Tmp0
2
    andi Tmp0, (1 << TOV1)    ; Wurde Overflow-Flag gesetzt?
3
    out TIFR1, Tmp0           ; Reset Overflow-Flag, falls gesetzt
4
    breq    counting_down
5
counting_up:                  ; Overflow-Flag war gesetzt
6
    ...
7
    ...
8
    rjmp   weiter_gehts
9
counting_down:                ; Overflow-Flag war nicht gesetzt
10
   ...
11
   ...
12
weiter_gehts:
13
   ...
Gast #4322475
Lesenswert?
• ▲
▼
Ich nutze "Phase and Frequency Correct PWM".
Wenn ich im TIMER1_COMPA_vect zum PWM-Puls-Beginn etwas anderes auslösen 
will als am Ende, muss ich ja wissen ob der Counter gerade am hoch- oder 
runterrennen ist.
Konkreter: ich möchte, dass nur während der PWM-On-Phase der Comparator 
aktiv ist.
Andere Vorschläge sind gerne willkommen.
Derzeit schaue ich in der ISR ob TCNT1 größer als OCR1A ist.
Bei clk/1 funktioniert das scheinbar zuverlässig.
Gast #4323567
Lesenswert?
• ▲
▼
OC schrieb:

> Ich nutze "Phase and Frequency Correct PWM".
> Wenn ich im TIMER1_COMPA_vect zum PWM-Puls-Beginn etwas anderes auslösen
> will als am Ende, muss ich ja wissen ob der Counter gerade am hoch- oder
> runterrennen ist.

Ja, das stimmt. Die Frage ist aber immer noch: ist das überhaupt nötig?

> Konkreter: ich möchte, dass nur während der PWM-On-Phase der Comparator
> aktiv ist.

Die Frage ist immer noch: ist das überhaupt nötig?

> Derzeit schaue ich in der ISR ob TCNT1 größer als OCR1A ist.
> Bei clk/1 funktioniert das scheinbar zuverlässig.

Sicher nicht. Wenn sich der OCR-Wert ausreichend dem TOP-Wert genähert 
hat, wird es nicht mehr vernünftig funktionieren, das liegt so klar auf 
der Hand, das man nichtmal ernsthaft drüber nachdenken muss.

Aber selbst wenn das irgendwie möglich wäre: Man käme dann sofort 
unmittelbar zu der Frage: Was soll eigentlich der Comparator leisten, 
wenn er im Extremfall nur für einen einzigen Clock-Tick eingeschaltet 
wäre... Insbesondere unter Berücksichtigung der Tatsache, dass er 
"synchronisiert" ist, innerhalb eines Taktes also schon bezogen auf den 
rein digitalen Aspekt unmöglich ein sinnvolles Ergebnis liefern kann, 
von der Grenzfrequenz der analogen Scheiße mal ganz abgesehen...

Fazit: Du solltest nicht darstellen, welche Detail-Lösung du nicht 
gebacken bekommst, sondern das Gesamtproblem. Nur das ermöglicht, dir 
SINNVOLLE *GESAMTKONZEPTE* vorzuschlagen. Die dann üblicherweise dein 
unlösbares Detailproblem überhaupt nicht mehr aufwerfen...

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren