ATmega: Wie prüfen, ob innerhalb einer ISR

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.. ?

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

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.

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

Warum musst du das denn wissen?

Wie unterscheidet sich denn die wirkung der funktion?

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.

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


Das macht man doch so:

1

 uint8_t  u8Temp = SREG;

2

 cli();

3

 ...atomare Aktion...

4

 SREG = u8Temp;

5

 ...

Somit hast du keine Probleme, wie es vorher war.

@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

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:

1

Eintritt -- automatisches cli

2

atomare_funktion();

3

Austritt -- reti macht implizit sei

Sonstwo:

1

cli

2

atomare_funktion();

3

sei

4

weiter gehts...

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

gekauft :)

Danke Leute !