ELEKTRO FORUM

Sven Schulz wrote:

>Wenn ich jemanden, oder Jemand mir, etwas verständlich machen
>möchte, das innerhalb einer Mikrokontrollers nach menschlichem
>ermessen parallel abläuft

Tut es ja gewöhnlich nicht, von solche Teilen wie dem
"Propeller" mal
abgesehen. Schließlich hast du bei den allermeisten µC halt nur
einen
Kern.

>wie kann ich das am einfachsten auf
>einem Blatt Papier darstellen?
>
>Ablaufdiagramm?

Klar. Im Prinzip läufts darauf hinaus, daß es mehrere
Ablaufdiagramme
gibt, nämlich für jede Ebene der Interrupthierarchie eines. Jedes
dieser
Ablaufdiagramme hat einen Anfang und ein Ende, mit Ausnahme dessen der
niedrigsten Hierarchieebene (des Hauptprogramms), das hat nur einen
Anfang und mündet in eine Endlosschleife. (Alles, was anders aussieht,
ist ein Bug! ;o)

Nun muß man nur noch die Diagramme in der Reihenfolge ihrer
Prioritäten
nebeneinanderlegen und sich klarmachen, daß die Teile mit der
höheren
Priorität zwischen jedem Paar von atomaren Operationen der niedriger
priorisierten Teile sozusagen als void Unterprogramm(void) laufen
kann , wobei das Auftreten eines Hardwareereignisses darüber
entscheidet, ob es abläuft.

>Sicherlich könnte man den Programmcode durchgehen. Das wird aber
>sehr schnell sehr ermüdent, Kernprobleme bleiben da oft lange
>unentdeckt.

Das Kernproblem von geschachtelten Interruptroutinen hat sehr viel
Ähnlichkeit mit dem Kernproblem von präemptiven Multitasking. Nicht
der
Ablauf der einzelnen Tasks ist schwierig zu verstehen, nur die
Interaktionen zwischen den Tasks.

Und die Lösung ist auch ganz ähnlich. Man minimiert die
Synchronisationspunkte, isoliert sie und erklart die Abläufe an diesen
Stellen als Statusmaschine.

Und hier wirds sogar etwas einfacher als bei präemptiven MT. Hier kann
nämlich immer nur einer der Partner (der am höchsten priorisierte)
seinen Status wechseln, während der Status aller anderen Beteiligten
sicher konstant wie vorgefunden bleibt.

Richtig schwierig wird es eigentlich erst, wenn das µC-Teil so gut
ausgelastet ist, daß zusätzlich zu den expliziten und gewollten
Interaktion zwischen den Abläufen auch noch die ungewollten durch
Resourcenverbrauch (RAM und Rechenzeit) wichtig werden.
Da kann dann so manche Milchmädchenrechnung auch mal nicht aufgehen. Man
bemerkt das in erster Instanz durch unmotivierte Abstürze und bei
genauerer Analyse daran, daß es Stack-Überläufe gibt.

Wenn es keine Hardwareunterstützung für diese Sache gibt, sollte es
zumindest in der Debug-Version also immer Code geben, der das prüft.
Blöd nur, daß der bei häufigen Interrupts sehr viel Rechenzeit
kostet.
Manchmal wird dadurch der eigentlich gewollte Hütehund zum Wolf.

Letztlich helfen also nur zwei Sachen wirklich: Kompetenz und Erfahrung.
Ein Anfanger wird komplexe Fehlerszenarios in solchen Systemen niemals
lösen. Auch nicht mit einer "1A"-Dokumentation, gleich welcher
Art. Die
helfen nur dem Profi, der kann sich schneller dem Kern des Problems
nähern.