ATmega: Wie prüfen, ob innerhalb einer ISR

[Gerrit Herzig (Gast)]

Hallo zusammen !

Ich habe das Problem, dass ich eine Funktion habe, die ich sowohl im 
main als auch in einer ISR benutze.

In dieser Funktion muss ich erkennen können, ob sie innerhalb einer ISR 
oder aus dem normalen Programm heraus aufgerufen wird.

Wie geht das ?

Viele Grüße,
Gerrit

[Gast123 (Gast)]

Evtl. könntest Du der Funktion einne zusätzlichen, eigentlich nicht 
notwendigen Parameter übergeben.. ? Von der normalen Funktion aus ne 1, 
von der ISR aus ne 2.. ?

[Peter (Gast)]

könnte man nicht einfach abfrage ob die Interrupts disable sind? Wenn ja 
ist man innerhalbt der ISR sonst nicht.

[ichichich (Gast)]

also wenn ein interrupt eintritt, dann wird das I Flag im SREG gelöscht 
und erst nach dem ausführen des interrupts wieder gesetzt.
es gibt afaik sogar nen eigenen befehl mit dem du überprüfen kannst ob 
das flag gesetzt ist.
wenn du im Programm selbst interrupts immer aktiviert hast(!), dann 
kannst du das so machen, sonst musst du halt eine variable setzen oder 
so.

[spess53 (Gast)]

Hi

>Ich habe das Problem, dass ich eine Funktion habe, die ich sowohl im
>main als auch in einer ISR benutze.

Ist eigentlich die ungünstige Variante. ISR sollte man so kurz wie 
möglich halten. Ist aber im Einzelfall zu entscheiden und kein Dogma. Im 
Normalfall setzt man in der ISR ein Flag und führt die Aktionen in der 
Main aus. Ansonsten siehe Gast123.

MfG Spess

[Matthias L. (Gast)]

Warum musst du das denn wissen?

Wie unterscheidet sich denn die wirkung der funktion?

[Gerrit Herzig (Gast)]

Hi !

Die Regeln mit "in ISR nur flaggen und im Main machen" sind mir bekannt 
und bewusst, kann ich aber hier nicht anwenden, da mein Main blockende 
Elemente enthält.


zur Erklärung: die Funktion fürt eine atomare Operation aus (cli/sei).
Innerhalb des Interrupts sollte ich aber auf das cli/sei tunlichst 
verzichten, weil ich sonst Reentranzprobleme bekomme.

ich weiss, das klingt eklig, ist derzeit so.
Die alternative wäre, das gesamte Design umzukrempeln. Da das Projekt 
aber eine Deadline hat, muss ich jetzt mit diesem Übel leben.

[Matthias L. (Gast)]

>eine atomare Operation aus (cli/sei).
>Innerhalb des Interrupts sollte ich aber auf das cli/sei tunlichst


Das macht man doch so:

 uint8_t  u8Temp = SREG;
 cli();
 ...atomare Aktion...
 SREG = u8Temp;
 ...

Somit hast du keine Probleme, wie es vorher war.

[Gerrit Herzig (Gast)]

@Matthias Lipinsky

Autsch, ja, hast recht. Danke !

Problem gelöst. Da stand ich mal wieder arg auf dem Schlauch.

Thread kann geschlossen werden !

Viele Grüße,
Gerrit

[Eddy C. (chrisi)]

Das ist aber doch eine Standardsituation:

- Momentanen Interrupt enabled/disabled-Status auf den Stack pushen
- Interrupts disablen
- Atomare Opration ausführen
- Interrupt enabled/disabled vom Stack poppen und setzen

[Eddy C. (chrisi)]

Hm, zu spät :-) over and out

[Sven P. (Gast)]

Spricht was dagegen, statt der Abfrage nach ISR oder nicht-ISR die 
'atomare' Funktion nicht-atomar zu gestalten und das cli+sei außerhalb 
zu machen?

In einer ISR:

Eintritt -- automatisches cli
atomare_funktion();
Austritt -- reti macht implizit sei

Sonstwo:

cli
atomare_funktion();
sei
weiter gehts...

[Gerrit Herzig (Gast)]

Ja, das war eine Frage aus der Kategorie Brett vorm Kopf.

Ich hätte ja auch einfach mal ins Listfile gucken können, wie die ISRs 
das selber regeln...

zum Thema sei()/Cli() rausziehen: ich benutz die Funktion alle naselang 
und müsste alle Naselang auf das sei aufpassen...

Also: Danke an alle Mitdenker und schönes Wochenende

[Simon K. (simon)]

Matthias Lipinsky wrote:
> Das macht man doch so:
>

>  uint8_t  u8Temp = SREG;
>  cli();
>  ...atomare Aktion...
>  SREG = u8Temp;
>  ...
>

oder

ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
{
    ...atomare Aktion... ;)
}

benötigt den Header util/atomic.h

[Gerrit Herzig (Gast)]

gekauft :)

Danke Leute !