Funktionen aus Intterupt aufrufen

Ja

Da hier keine  Controllerfamilie genannt wurde, unterstelle ich mal, daß 
es sich hier um AVRs handelt.

amateur schrieb:
> Was machst Du eigentlich, wenn die Funktion mehrfach, gleichzeitig
> aufgerufen wird?
Wird sie das denn? Von wem denn? Ein mehrfacher Aufruf einer Funktion 
kann aus sich selbst heraus erfolgen oder wenn sie sowohl im 
Hauptprogramm oder einer seiner Verzweigungen als auch in einer ISR 
aufgerufen werden kann.

amateur schrieb:
> Oder sind deine Unterbrechungen so nett nicht gleichzeitig aufzutreten?
Das ist vollkommen egal. Entscheidend ist, wann sie abgearbeitet werden.
Und das geht beim AVR immer schön der Reihe nach.
Auch bei anderen Controllern mit Prioritätssteuerung werden sie das, 
solange die Priorität gleich ist.
Womit dieses Problem überhaupt nicht auftreten kann:

amateur schrieb:
> Man sollte aber nie den zeitlichen Aspekt aus den Augen verlieren. Auch
> die Problematik des Zugriffs, von mehreren Stellen aus, auf die gleichen
> Variablen, lässt sich nicht nur auf: Definieren wie sie einfach als
> "volatile" reduzieren.

Das Problem des Zugriffs auf eine Variable von mehreren Stellen entsteht 
nur dann, wenn die Funktion im Hauptprogramm abgearbeitet wird, die 
Variablen aber in mehreren ISRs verändert werden können und die 
Variablenbehandlung in der Funktion nicht atomar erfolgt. Wobei dann 
eine atomare Abarbeitung erst wieder für Timigprobleme sorgen kann. Weil 
jetzt nicht nur die anderen Interrupts die Ausführung einer ISR 
verzögern können, sondern auch das Hauptprogramm.
Bei der Abarbeitung der Funktion in einer ISR treten all diese Probleme 
gar nicht erst auf.

Die Funktion kann selbstvertständlich in einer ISR ausgeführt werden. 
Irgendwo muss man sie ja abarbeiten. Daß die Zeit dafür so kurz sein 
muß, daß die anderen Funktionsaufrufe dadurch nicht beeinträchtigt 
werden und die aktuelle ISR in jedem Fall fertig sein muß, bevor ein 
erneuter Aufruf erfolgt, sollte dabei klar sein. Aber selbst wenn das 
auftritt hat das allenfalls eine unerwartete Programmausführung zur 
Folge, z.B. daß beim Multiplexen die LEDs nicht gleichmässig leuchten 
oder der UART ein Byte verschluckt.
Stacküberläufe und damit verbundene Abstürze kann es dabei nicht geben, 
da auch dieser IRQ die laufende ISR nicht unterbrechen kann.
Nicht das ewig heruntergebetete "So schnell wie möglich" sondern "So 
schnell wie nötig" ist das Ziel. Wenn das nicht passt, ist das Timing an 
sich das Problem.
Dieses Timingproblem hätte man aber in verschärfter Form auch bei der 
"Flaglösung" wodurch die Probleme erst geschaffen werden.
Dauert das Abarbeiten einer Funktion allerdings länger als ein 
ISR-Interval, muß diese in der Hauptschleife aufgerufen werden. Dann 
sollte allerdings das Flag setzen und damit der Funktionsaufruf, erst 
erfolgen wenn die Funktion fertig. Sollte das Flag vorher gesetzt werden 
kann es aber auch hierbei nicht zu einem mehrfachen Aufruf der Funktion 
kommen.
Aber dann ist wieder das gesamte Timing eher fragwürdig.

NurEinGast schrieb:
> Darüber nachdenken und wissen was man tut ist immer gut.
> Aber wer schon mal was von reentrance gehört hat, der darf natürliche
> funktionen aus der ISR aufrufen.
> Und in der Funktion die der ledfreund angegeben hat ist kein Pointer
> übergeben, keine globalben variable genutzt ........
> Du hast recht - man muss wissen was man tut.
Natürlich muss man wissen, was man tut. Aber man sollte auch die 
richtigen Schlüsse daraus ziehen.

mfg.

Peter II schrieb:
> Die funktionen sollte aber selber "reentrant" programmiert sein.

Das sind in der Regel nur Funktionen, die etwas berechnen und keine 
statischen Variablen anlegen.

Funktionen, die IO-Ressourcen benutzen (Ports, Timer, UART, SPI, LCD 
usw.) sind es oft nicht.
Einen schönen Zeichensalat gibt es z.B., wenn Main und Interrupt 
gleichzeitig auf ein LCD zu schreiben versuchen.

Eine weitere Fallgrube sind Funktionen mit atomaren Abschnitten. Diese 
müssen dann den Interruptstatus sichern und restoren.

Peter Dannegger schrieb:
> Eine weitere Fallgrube sind Funktionen mit atomaren Abschnitten. Diese
> müssen dann den Interruptstatus sichern und restoren.

Nicht solange sie nur in ISRs aufgerufen werden und nicht schachteln.