Fragen zum Unterschied SREG und sei() ?

[Julian K. (fragenkinsey)]

Hallo Community,

A.sollten ich bei der Übergabe des Vergleichswertes des Compare match 
mode in die Register OCR1AH und OCR1AL das Statusregister auf "i" setzen 
und löschen, um alle Interrupts zu unterbinden bzw. zu gewähren oder 
benutzt man da einfach sei()und cei()?

B.Könnt ihr mir vielleicht auch gleichzeitig den Unterschied zwischen 
den beiden Aktivierungs-/Deaktivierungsmöglichkeiten beschreiben. Dass 
das SREG sozusagen auf globaler ebene die Interrupts aus und anmachen 
kann, habe ich schon verstanden. sei() und cei () müssten nach meinem 
Verständnis das gleiche auf lokaler Ebene machen können.

C.Bis jetzt bin ich der Meinung, dass An- und Ausmachen durch SREG die 
überlegene Variante ist. Warum aber benutzt man dann überhaupt noch 
sei() und cei()?

kind regards
fragenkinsey

[Karl H. (kbuchegg)]

Julian Kinsey schrieb:
> Hallo Community,
>
> A.sollten ich bei der Übergabe des Vergleichswertes des Compare match
> mode in die Register OCR1AH und OCR1AL das Statusregister auf "i" setzen
> und löschen, um alle Interrupts zu unterbinden bzw. zu gewähren oder
> benutzt man da einfach sei()und cei()?

Was immer du mit 'auf i setzen' auch meinst.
die Funktionen sei() und cli() machen nichts anderes, als das 
entsprechende Bit im Statusregister zu setzen bzw. zu löschen.
D.h. du musst dich aus Sicht eines C-Programmierers nicht mehr mit einem 
Statusregister (was ist das?) rumschlagen und welches Bit dort zu setzen 
ist, sondern als C-Programmierer benutzt du einfach cli() um 
auszudrücken "generelle Interruptfreigabe sperren" bzw. sei() um 
auszudrücken "generelle Interrupt Freigabe ist erteilt". Das da das SREG 
involviert ist und ein bestimmtes Bit dieses bewirkt, ist zwar nett, 
aber nichts was dich als C-Programmierer interessiert. Und auch nicht 
interessieren sollte.
Du kümmerst dich ja auch nicht um das Overflow-Bit im Statusregister, 
bzw. die restlichen Register r0 bis r31 des Prozessors. Diese Register 
stehen allesamt unter Verwaltung des Compilers und sind nichts, was dich 
groß was angeht bzw. worum du dich kümmern solltest bzw. müsstest.


> Dass das SREG sozusagen auf globaler ebene die Interrupts aus
> und anmachen kann, habe ich schon verstanden. sei() und cei ()
> müssten nach meinem Verständnis das gleiche auf lokaler Ebene
> machen können.

es gibt keine 'lokale Ebene'. Was soll das sein, eine lokale Ebene?
Entweder die Interrupts sind generell zugelassen oder sie sind es nicht.

[Julian K. (fragenkinsey)]

Da habe ich wohl etwas falsch verstanden, was das Setzen mit dem i 
betrifft.

danke für deine erhellende Erklärung.

fragenkinsey

Nachtrag: Auch herzlichen Dank für deine Nachträge

[Jörg W. (dl8dtl) (Moderator)]

Der wesentliche Punkt bei sei() und cli() ist, dass die entsprechenden
Befehle schneller sind als eine „zu Fuß“-Manipulation von SREG.

[Sascha W. (sascha-w)]

@Julian

zu A)
warum willst du beim laden der OCR-Register die Interrupts überhaupt 
ausschalten? Das ist nicht notwendig. Auch wenn der 16-Bit-Wert in zwei 
Registern gespeichert ist, so erfolgt das Update des 16-Bit OCR Werts 
(wie auch der aller anderen 16-Bit Werte) intern auf einmal - dazu wird 
vom Controller ein temporäres Register genutzt.

Sascha

[c-hater (Gast)]

Sascha Weber schrieb:

> zu A)
> warum willst du beim laden der OCR-Register die Interrupts überhaupt
> ausschalten? Das ist nicht notwendig

Kommt drauf an. Wenn in irgendeiner ISR ebenfalls auf 16-Bit-Register 
des Timers zugegriffen wird, ist das sogar sehr notwendig.

> so erfolgt das Update des 16-Bit OCR Werts
> (wie auch der aller anderen 16-Bit Werte) intern auf einmal - dazu wird
> vom Controller ein temporäres Register genutzt.

...welches für alle 16-Bit-Register des Timers geshared wird...

Die Implikationen dieses Sachverhaltes müßten doch auch für 
C-Programmierer verständlich sein, oder?

Na klar, es entlarvt die LÜGE, daß einem der Compiler alle Sorge um die 
Hardware des Zielsystems abnimmt, gnadenlos als solche, aber das kann 
man im Sinne der reinen Lehre natürlich getrost ignorieren...

C-ler sind irgendwie wie islamische Taliban oder erzkonservative 
Katholiken. Was nicht in's Weltbild paßt, wird einfach ausgeblendet.

[Karl H. (kbuchegg)]

ist schon gut c-hater.

Ein Hinweis darauf, dass wegen möglichen Interrupts und gleichzeitigem 
Zugriff auf andere Register das trotzdem ein Problem sein könnte, hätte 
es auch getan.

Denn genau dasselbe Problem stellt sich auch für 
Assembler-Programmierer. und die ignorieren das genau so geflissentlich.

[holger (Gast)]

>C.Bis jetzt bin ich der Meinung, dass An- und Ausmachen durch SREG die
>überlegene Variante ist. Warum aber benutzt man dann überhaupt noch
>sei() und cei()?

SREG zu benutzen kann durchaus Sinn machen.
Man stelle sich vor das Hauptprogramm hat die Interrupts
deaktiviert. Jetzt ruft man ein Modul auf wo es Sinn macht
Interrupts zu verbieten um Probleme zu vermeiden. Also
erst mal cli() und dann wenn man fertig ist sei(). Jetzt
hat dieses Modul die Interrupts wieder freigeschaltet
obwohl das Hauptprogramm das überhaupt nicht gebrauchen kann!

Es ist immer eine Frage der Anwendung ob man sei() oder
SREG benutzt.

[Uwe (Gast)]

Hi,
>Jetzt ruft man ein Modul auf wo es Sinn macht Interrupts zu verbieten um 
>Probleme zu vermeiden. Also erst mal cli() und dann wenn man fertig ist >sei()
falsch, wenn ich schon eine solche besch. Sub habe dann doch bitte mit
Sicherung SREG -> cli -> mein Programm -> Zurückschreiben SREG

einen schönen Tag noch, Uwe

[holger (Gast)]

>>Jetzt ruft man ein Modul auf wo es Sinn macht Interrupts zu verbieten um
>>Probleme zu vermeiden. Also erst mal cli() und dann wenn man fertig ist >>sei()
>falsch, wenn ich schon eine solche besch. Sub habe dann doch bitte mit
>Sicherung SREG -> cli -> mein Programm -> Zurückschreiben SREG

Genau das meinte ich doch;)
sei() ist der Holzhammer mit dem man sich ganz schnell
aufs eigene Knie hauen kann.

>eine solche besch. Sub

Meinst du damit "beschissene Sub"?
Wenn man Module schreibt wo man nicht weiss ob die Interrupts
verboten worden sind, es aber sinnvoll ist Interrupts zu verbieten,
kommt man um das SREG sichern nicht drum rum.
Egal was in SREG drin war, man kommt sauber wieder raus aus dem Modul.
Das kann z.B. eine ganz einfache LCD Routine sein die an einem
Port an einem oder mehreren Bits wackelt.

[Peter D. (peda)]

Es ist mir bisher noch nie passiert, daß ich mal den Überblick verloren 
hätte, wann Interrupts disabled oder enabled sind.

Disabled sind sie nur in den Init-Routinen, in der Mainloop sind sie bei 
mir enabled, sonst wären Interrupts ja witzlos.

Ich benutze daher ausschließlich:

ATOMIC_BLOCK(ATOMIC_FORCEON){
// ...
}

[(prx) A. K. (prx)]

Peter Dannegger schrieb:
> Es ist mir bisher noch nie passiert, daß ich mal den Überblick verloren
> hätte, wann Interrupts disabled oder enabled sind.

Es gibt schon gelegentlich Fälle, in denen eine (kleine) Routine mal mit 
eingeschalteten und mal mit ausgeschalteten Interrupts aufgerufen wird. 
In dem Fall wärs blöd, wenn darin abschliessend fest SEI drin steht, 
statt SREG wiederherzustellen.