warum darf ich in einer ISR kein "Krieg und Frieden" machen, wenn der Anwendungsfall das zulässt ?
Wenn ich nur eine einzige Anwendung mit nur einem Interrupt laufen habe, kann ich, bis auf ein paar spezielle Ausnahmen, die Anwendung genausogut im Main Programm laufen lassen.
Ein Interrupt soll ja möglichst schnell auf ein "Ereignis" reagieren.
Das funktioniert aber dann schon nicht mehr richtig, wenn bei 2 Interrupts einer "Krieg und Frieden" spielt. Der zweite Interrupt kann da sehr häufig durch den langen verzögert werden.

Für Dich als erfahrenen Programmierer ist es sicher kein Problem abzuschätzen, ob Du dir eine lange Interruptroutine leisten kannst oder nicht.
In 99% aller Anwendungsfälle wird man aber zu möglichst kurzen Interruptroutinen greifen müssen.
In einer Interruptroutine z.B. auf die Änderung eines Portzustandes zu warten, der eventuell nie eintritt, blockiert die komplette Abarbeitung des weiteren Programmes.
Ich versuche, soweit das irgendwie möglich ist, den weiteren Programmablauf fortzuführen (z.B. mit Zeitüberwachungen), auch wenn ein erwartetes Eingangssignal nicht kommt. Das Ganze natürlich im Main Programm.
Beispiel:
Ich starte einen externen A/D Wandler und warte auf ein "Conversation Ready".
Allerdings hat sich der A/D Wandler aufgehängt und tut schlichtweg gar nichts. In der "Ready" Warteroutine wird ein Timer abgefragt.
Erreicht dieser Timer einen Wert der höher ist als die maximale "Conversation Time" wir ein Fehlerzähler hochgezählt.
Wenn dieser Fehlerzähler den Schwellwert ( z.B. 3 ) erreicht wird der A/D Wandler resettet. Das Programm kann sich somit im Prinzip nicht festlaufen und liefert im schlimmsten Fall ( A/D Wandler defekt ) keine, bzw. falsche Wandlerergebnisse. Andere Subroutinen, wie eine Drehzahlmessung, können aber unabhängig davon weiterlaufen.