ELEKTRO FORUM

Hallo,

innerhalb von Mikrokontrollern habe ich die Chanche innerhalb
von sehr kurzer Zeit sehr viel abarbeiten zu lassen. Kommen
noch,jenseits des Pollings,geschachtelte Interrups dazu, begreift
das Ganze letztendlich nur noch derjenige der das Konzept des
dahinterstehenden Programmcodes erstellt hat. Oft ist der
Konzeptersteller und der Programmierer ein und dieselbe Person.

Wenn ich jemanden, oder Jemand mir, etwas verständlich machen
möchte, das innerhalb einer Mikrokontrollers nach menschlichem
ermessen parallel abläuft, wie kann ich das am einfachsten auf
einem Blatt Papier darstellen?

Ablaufdiagramm? Petrinetz?

Gibt es dafür ein Patentrezept oder läuft das auf eine Mischung
verschiedener Darstellungstechniken heraus?

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

Sven

Sven Schulz schrieb:
>
> innerhalb von Mikrokontrollern habe ich die Chanche innerhalb
> von sehr kurzer Zeit sehr viel abarbeiten zu lassen. Kommen
> noch,jenseits des Pollings,geschachtelte Interrups dazu, begreift
> das Ganze letztendlich nur noch derjenige der das Konzept des
> dahinterstehenden Programmcodes erstellt hat. Oft ist der
> Konzeptersteller und der Programmierer ein und dieselbe Person.
>
Aufruf-Verbindungslinien zwischen Interruptroutinen und normalem Programm
gibt es nicht, der Datenaustausch erfolgt über den Speicher, idealerweise
übergeben alle Routinen und das Hauptprogramm ihre Daten auch nur an
*einer* Stelle innerhalb ihres Ablaufs. Klassisch ist das eine
Event-Hauptschleife, die in einem FIFO ihren nächsten Auftrag abholt. Die
Eingabe-Interruptroutinen füllen den FIFO der Hauptschleife mit
Eingabedaten auf. Wenn man auch Aufgabe-Interruptroutinen hat, bekommen
dieses ebenfalls jeweils einen FIFO, in dem die Hauptschleife Daten zum
Raussenden ablegen kann -- dann kann die Hauptschleife in der Zeit mit was
anderem weitermachen.

Wenn man es richtig macht, hat man keinen Spaghetticode, der einander wild
mit unterschiedlicher Intention aufruft. Wenn man es anders macht, hat man
nicht nur ein Problem mit der Visualisierung, sondern meist auch mit der
Programmfunktion (daraus wächst dann der Wunsch nach Visualisierung des
Geraffels).

Mit freundlichem Gruß

Jan

"Jan Kandziora" <jjj@gmx.de> schrieb im Newsbeitrag
news:fb4nu9$kjg$1@online.de...
>
> Wenn man es richtig macht, hat man keinen Spaghetticode


Seh ich aehnlich.
Ich hatte noch keine Schwierigkeiten, Code uebersichtlich auf
einem Zettel darzustellen, auch wenn es ein Hauptprogramm und
eine Handvoll ereignisgesteuerter Interruptroutinen gibt.

Liegt vermutlich einfach daran, dass es von vorneherein sinnvoll
strukturierter Code war.

Dann braucht man aber eigentlich keine Diagramme, nur um den
allergroebsten Ueberblick zu geben (Prozesse nebeneinander,
Datenfluss dazwischen).

Aber wenn ich heutigen Studenten bei den Uebungsaufgaben zu
UML zusehe, verstehe ich, wieso man damit Probleme haben kann,
schliesslich ist entweder das Problem gegenueber dem Diagramm
total unterdimensioniert, oder die Diagramme waeren bei
echten Problemen komplett unuebersichtlich.

> Oft ist der
> Konzeptersteller und der Programmierer ein und dieselbe Person.

Das ist so weit ganz sinnvoll, schliesslich sollte derjenige,
der sich den Muell ausgedacht hat, es auch umsetzen, und nicht
meinen, die wirkliche Arbeit den anderen Deppen zu hinterlassen.
Prinzip Hewlett Packard (aus den guten Zeiten).
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read Art of Electronics Horowitz/Hill before you ask.
Lese Hohe Schule der Elektronik 1+2 bevor du fragst.

Am Thu, 30 Aug 2007 08:59:17 +0200 schrieb Stefan Brröring:

> Da erzählte mir doch letztes Jahr so ein Schlaumeier (abgebrochener
> Wirtschaftsinformatiker, jetzt Geschäftsführer bei einem
ehemaligen
> Kunden von mir), ich müsste ein Klassendiagramm für ein GCC
Programm
> vorlegen. Hab mir dann dazu mal was durchgelesen und bin zu dem Ergebnis
> gekommen, dass das für praktische Anwendungen, insbesondere wenn es
um
> Microcontroller geht, Unfug ist.

In dem Fall wahrscheinlich schon mangels Klassen ...

Lutz

--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für
Sensoren

Stefan Brr

Georg Acher schrieb:
> Aber Klassendiagramme bzw. Beziehungen lassen sich auch aus unbekannten
> Programmen per doxygen leicht rausfinden.
...was bei prozeduralem C aber nicht sehr erhellend ist, sofern die
Programm-Kommentare nicht Doxygen-"konform" angelegt sind.

> Selbst bei C-only-Programmen ist die Anzeige der Strukturverflechtungen
> manchmal praktisch.
Habe ich da bei Doxygen was

Thorsten Wahn <thorsten.wahn@t-online.de> writes:

>Habe ich da bei Doxygen was übersehen, was über die reine
Auflistung
>der Funktionen und Variablen hinaus geht?

Ja ;-) Du brauchst das dot-Paket zur Grapherzeugung und die Option
"CLASS DIAGRAMS=YES". Das visualisiert dann Klassen und auch normale
structs mit
ihren Abhängigkeiten.

--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

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.