AVR-GCC: schnelle(re)s PWM mit ISR_NAKED?

[Michael R. (Firma: Brainit GmbH) (fisa)]

Hallo zusammen,

ich hab mich wieder mal selbst überlistet und die falschen PWM-Pins 
gelayoutet (die von Timer1, ich brauch aber Timer2).

Dann halt zu Fuss, ist ja keine Krise: Es werden zwei PWM-Signale 
verwendet, in der ISR(TIMER2_OVF_vect) beide Bits einschalten, und in 
der jeweiligen ISR(TIMER2_COMPx_vect) das Bit wieder ausschalten. 
Funktioniert soweit gut.

Nun hab ich gesehen dass der Pro- und Epilog durchaus länglich sind, und 
der "eigentliche" Code nur zwei sbi bzw. je ein cbi.

Sowas sollte doch gefahrlos mit ISR_NAKED verbesserbar sein?

- da keine Register verwendet werden, müsste ich auch keine sichern?

- muss ich das SREG sichern? ich denke nicht...

- des Risikos, dass es bei einer Erweiterung der ISR in die Hose gehen 
kann, bin ich mir bewusst.


Danke schon mal, Michi

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Das Instructionset Manual sagt bei Flags: None

      
Mnemonics Operands Description                 Operation        Flags  #Clocks
SBI       A, b     Set Bit in I/O Register     I/O(A, b) ← 1    None   1/2 
CBI       A, b     Clear Bit in I/O Register   I/O(A, b) ← 0    None   1/2

Und wenn keine Flags beeinflusst werden, musst du auch das 
Statusregister nicht sichern...

[Peter D. (peda)]

Michael Reinelt schrieb:
> Nun hab ich gesehen dass der Pro- und Epilog durchaus länglich sind

Das stört aber erst, wenn es keinerlei andere Interrupthandler gibt.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Peter Dannegger schrieb:
> Michael Reinelt schrieb:
>> Nun hab ich gesehen dass der Pro- und Epilog durchaus länglich sind
>
> Das stört aber erst, wenn es keinerlei andere Interrupthandler gibt.

Ähhh... wie meinst du das?

Timer2 wäre exklusiv für PWM. Damit sind nach meinem Verständnis auch 
die beiden Interrupt-Handler (Overflow und Output-Compare) exklusiv. Und 
jede ISR kriegt ja ihren eigenen Pro-/Epilog, zumindest les ich das so 
aus dem erzeugten Assembler-Code.

[Peter D. (peda)]

Michael Reinelt schrieb:
> Ähhh... wie meinst du das?

Der maximale Jitter hängt von dem längsten Interrupthandler überhaupt 
ab. Denn der muß ja erst beendet werden.

Was anderes wäre es z.B. beim 8051. Da kann man den schnellen Interrupts 
die höhere Priorität geben. Sie unterbrechen dann einfach alle 
schnarchlahmen anderen Interupts.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Peter Dannegger schrieb:
> Michael Reinelt schrieb:
>> Ähhh... wie meinst du das?
>
> Der maximale Jitter hängt von dem längsten Interrupthandler überhaupt
> ab. Denn der muß ja erst beendet werden.

Ahja, verstehe. Allerdings sind die anderen Interrupts eher seltener, 
dieses PWM sollte so schnell (im Sinne von hoher Frequenz) wie möglich 
laufen. Idealerweise mit Prescaler 1, was ja "hardware-mäßig" kein 
Problem gewesen wäre, mit "Halb-Soft-PWM" aber schon. Wenigstens 
Prescaler 8 hätt ich gern verwendet, und da möchte ich auch nur ungern 
~10 Takte verschenken, wenns nicht sein muss.

[Ulrich (Gast)]

wenn wirklich nur SBI / CBI benutzt werden kann man auch gut und gerne 
ISR_naked nutzen. Zur Sicherheit wäre es dann besser den Code auch als 
Inline ASM zu schreiben, und nicht darauf zu vertrauen das der Compiler 
wirklich CBI / SBI nutzt.

Unabhängig davon muss man noch aufpassen bei PWM Werten an einem Ende. 
Wenn die beiden Interrupt Flags fast gleichzeitig gesetzt werden, so 
dass beide Interrupts gleichzeitig auf Ausführung warten, geht die 
Reihenfolge nach dem Interruptvektor, nicht nach der Reihenfolge in der 
die Falgs gesetzt wurden.  PWM Werte von 0,1 oder 254/255 sind deshalb 
ggf. Tabu oder müssten anders gelöst werden.

[Falk B. (falk)]

@  Michael Reinelt (fisa)

>ich hab mich wieder mal selbst überlistet und die falschen PWM-Pins
>gelayoutet (die von Timer1, ich brauch aber Timer2).

Dann nimm das Teppichmesser/Skalpell/Dremel, trenn die Verbindung und 
zieh Klingeldraht. Dauert 5 min und erspart sinnlosen 
Software-Workaround.