mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Artikel über Finite State Machines


Autor: Philipp K. (philippk) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich habe schon lange versprochen im embedded projects Journal einen 
Artikel über die Implementierung von Endlichen Zustandsautomaten zu 
schreiben. Nun bin ich in den Ferien endlich fertig geworden und habe 
mal eine erste Version.

Wenn jemand Zeit und Lust hat den Artikel mal durchlesen, wäre ich froh 
um Feedback, falls etwas noch nicht ganz so verständlich bzw. ich etwas 
noch umfangreicher beschreiben soll.

Die ganzen Source Dateien werde ich natürlich ins SVN Repo stellen 
(vorausgesetz ich bekomme ein Projekt ;-) sobald der Artikel fertig ist.

Grüsse Philipp

Autor: dunno.. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zum listing 5.1 würd ich vorschlagen, dass du zumindest auch einmal 
zeigst, dass der state auch innerhalb der case-anweisung gewechselt 
werden muss? könnte vielleicht für neueinsteiger recht hilfreich sein?

die realisierung über klassen in c++ ist mir neu, ich kannte nur switch 
case und eben die funktionszeiger in c.

wieder was gelernt. =)


mfg

und am rande hab ich noch einige tippfehler gefunden..

Raedy, Acktion..

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Philipp,

die Beschreibung, was ein Moore-Automat sein soll, finde ich schon sehr 
schwammig. Bevor da eine nicht-korrekte Definition oder sowas kommt, 
würde ich das ganze eher weglassen. Zur ersten Veranschaulichung wäre 
ein kleines Diagramm mit zwei oder drei Zuständen und wenigen 
Transitionen auch nicht schlecht, da man sich das besser vorstellen kann 
als Zustandslogik, Zustandsspeicher etc.
Mir persönlich ist es so viel zu informal und oft auch viel konkreter 
dargestellt, als es wirklich ist. Allerdings bin ich auch nicht 
derjenige, den du mit dem Artikel ansprechen möchtest.

In manchen Diagrammen sind übrigens noch Rechtschreibfehler, z.B. 
Zustnad oder Raedy...

Autor: Über die Schulter-Gucker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Philipp,
auf Deiner Tastatur scheint die Komma-Taste teilweise defekt zu sein. 
Oder liegts am Finger, oder an der Ansteuerung desselben?

Autor: Thomas Z. (tezet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin kein Automaten-Theoretiker.

4.1.1. Zustände
Reihenfolge ändern: Entry --> Do --> Exit
Klärung, ob immer alle Actions vorhanden sein müssen oder nicht; muss 
mindestens einer da sein?

Das Diagramm würde ich aber vollständig darstellen:
Zustand A: Entry, Do, Exit
Zustandswechsel: Bedingung
Zustand B: Entry, Do, Exit

Dann kann man auch die genaue Reihenfolge erklären:
...
Bedingung erfüllt --> also Wechsel
Zustand A::Exit
Zustand B::Entry

Vielleicht Beispiel Serielle Schnittstelle nehmen
Extern: Telegramm in einen Transferbuffer schreiben und Automaten 
anstoßen
Entry: Schnittstelle auf Senden schalten
Do: ein Byte senden
Exit: Schnittstelle auf Empfangen schalten

5.2. Funktionsbeschreibung

statt gleich den Fehlerfall zu beschreiben, würde ich mit der eigentlich 
normalen Funktion anfangen und zuletzt auf den Fehlerfall zu sprechen 
kommen:
...Sobald man im Zustand Bereit die Start Taste drückt wechselt der 
Toaster in den Zustand Toast einziehen. Dazu muss sich der Motor nach 
links drehen. Erst wenn der Endschalter durch die Schublade gedrückt 
wird, kann dieser Zustand verlassen werden, der Motor wird gestoppt und 
der neue Zustand Toasten wird erreicht...

Autor: Philipp K. (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich möchte euch allen bereits jetzt danken für die Unterstüzung. Beim 
Kapitel zum Moore Automaten werde ich mir noch was einfallen lassen wie 
man das besser erklären könnte, und bei der UML Notation bin ich auch 
bereits an einen zusätzlichen Beispiel dran.

Ob der Beispielcode auf dem AVR genug verständlich ist würde mich noch 
interessiren, ob der genügend detailiert ist.

Für Rechtschreibfehler bin ich nätürlich auch immer dankbar. Ich 
befürchte jedoch dass ich das Wort ready auch in 100 Jahren noch nicht 
richtig schreiben kann.
P.S. meine Tastatur scheint in Ordnung, ich habe das Problem etwa 30cm 
vor dem Bildschirm lokalisiert.

Autor: Philipp K. (philippk) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier mal die aktuelle Version inklusive der Sourcen. Im Wiki 
existiert jetzt auch ein Artikel dazu [[Implementierung einer Finite 
State Machine]]

Autor: Thomas B. (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Phillip,

super Dokument!! Vor allem fand ich die Erklärung der TickFunktion sehr 
interessant, da mir nicht  klar war, wie ich langdauernde Aktionen, die 
innerhalb eines Zustandes normalerweise in einer Schleife bearbeitet 
werden so realisieren kann, dass auch auf Zustandsänderungen reagiert 
werden kann ohne in jeder Schleife auf Zustandsänderungen zu testen.

Gruß
Thomas

Autor: Kan a. (Firma: Basta) (kanasta)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh Gott, 21 Seiten über Toaster, Automaten, und dann auch noch UML...
Auch wenn ich manchmal ganz gern im Embedded Journal stöbere, würde ich 
diesen Artikel garantiert nicht lesen.
Tut mir leid, aber ich hätte ein anderes Thema gewählt...

Autor: micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kan asta schrieb:
> aber ich hätte ein anderes Thema gewählt...

Dann nicht blöd schnacken, MACHEN!!!

Autor: Kan a. (Firma: Basta) (kanasta)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
keine zeit. das war auch eher so eine floskel, um meine unzufriedenheit 
mit der themawahl auszudrücken.

Tut mir leid, aber ein anderes Thema wäre sicherlich spannender...

Autor: TM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja das Thema muss ja nicht jedem gefallen...
Ich finde soetwas schon spannend und interessant.
Würde ich geren in der Embedded Journal lesen.

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Philipp,

ich finde den Artikel Klasse, habe aber auch ein bisschen zu meckern:
1) Formal gesehen hat weder der Moore- noch der Mealy-Automat eine 
Clock. Das ist ein Fehler bzw. eine Unklarheit die beseitigt oder 
erklärt gehört.
2) Abbildung 3.1 würde ich derart umgestalten, dass Zustandslogik und 
-speicher (sofern du diesen Block belassen willst, siehe Punkt 1), links 
stehen und den Block "Ausganslogik" nach rechts verschieben. Das sollte 
ein klareres Bild mit weniger "verwuselten" Pfeilen geben.
3) Zitat: "In der Softwareentwicklung wird für endliche Automaten meist 
der Moore-Automat verwendet [...]". Das ist schon eine Behauptung, für 
die ich erstmal eine Quelle sehen möchte. Weiter geht's mit "[...] der 
Moore-Automat verwendet, welcher sein Ursprung in der Digitaltechnik 
hat.". Ich muss gestehen, ich bin nicht so fit in der Historie, aber ich 
denke der Ursprung war die Automatentheorie.
4) Ein paar Rechtschreibfehler, nicht passende Referenzen, etc ...

Autor: Thomas B. (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eines ist mir noch nicht ganz klar. Sollte man nicht noch irgendwo den 
vorherigen Zustand speichern? Schließlich kann es vorkommen, dass die 
Entryfunktion sich unterschiedlich verhalten muss, je nach vorherigem 
Zustand.
Oder habe ich dann einen Fehler in meiner State machine wenn das 
notwendig ist?

Gruß
Thomas

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Schließlich kann es vorkommen, dass die
> Entryfunktion sich unterschiedlich verhalten muss, je nach vorherigem
> Zustand.

Wenn das so ist, dann hast Du zuwenige Zustände...

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Thomas Burkhart (escamoteur)

>Oder habe ich dann einen Fehler in meiner State machine wenn das
>notwendig ist?

Ja.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> kann es vorkommen, dass die
> Entryfunktion sich unterschiedlich verhalten muss, je nach vorherigem
> Zustand.

Ein "netter" Hack zur Lösung solcher Designfehler ist eine einfache 
interne Statemachine innerhalb einzelner Zustände. Wie jeder Hack kann 
solch eine Lösung allerdings in der Zukunft zu unabsehbaren unschönen 
Folgen führen ;)

Oliver

Autor: Thomas B. (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard M. schrieb:
> Thomas Burkhart schrieb:
>> Schließlich kann es vorkommen, dass die
>> Entryfunktion sich unterschiedlich verhalten muss, je nach vorherigem
>> Zustand.
>
> Wenn das so ist, dann hast Du zuwenige Zustände...

Wenn es sich nur um geringfügig anderes Verhalten handelt, wächst doch 
mein Code unnötig an, wenn ich jede einzelne Variante als eigenen 
Zustand modelliere.

Gruß
Thomas

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas Burkhart (escamoteur)

>Wenn es sich nur um geringfügig anderes Verhalten handelt, wächst doch
>mein Code unnötig an, wenn ich jede einzelne Variante als eigenen
>Zustand modelliere.

Nö, du bringst nur mehr Chaos in deine Software. Die paar Bytes tun 
nicht weh, vor allem wenn du sowieso die Infromatiionen irgendwie 
speichern musst.
Mein Tip. Mach es richtig und spar dir die "Abkürzungen".

MFG
Falk

Autor: Philipp K. (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas Burkhart
Meiner Meinung nach würde dies das "information hiding Konzept" 
verletzen wenn ein Zustand seine Vorgeschichte kennt. Es gibt aber zwei 
Wege das Problem zu lösen:
  1) Ev. kann ein Teil der Entry Action in die Exit Action des 
Vorgännger Zustandes verschoben werden
  oder 2) Wie schon genannt einen Zwischenzustand einfügen.

Gruss
Philipp

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann will ich mal meckern.

2. Hier sollte und muss man schon ein paar gute Sätze mehr 
"verschwenden" um dem uniformierten Leser den Sinn und Zweck eines 
Automaten zu erklären. Für Leute die sich auskennen schreibt man das 
nicht.

3. Man merkt, der Autor hat wenig Geduld, mal ein paar grundlegende 
Dinge mit Ruhe zu erklären, es drängt ihm zu Code. Das ist aber nicht 
gut. Auch die Formulierungen sind bisweilen unglücklich.

"Ein Moore Automat besteht im wesentlichen aus drei Teilen."

Hier sollten dieser erstmal aufgezählt werden, bevor es mit einer 
Erklärung weiter geht.

Und Denglisch ist ein Zeichen von schlechter Qualität. Das gute, alte, 
DEUTSCHE Wort Takt bedarf keiner Anglizismen. Und "ein clock" tritt nie 
auf, bestenfalls mal ein Takt(schritt).

Weiter geht es mit Events, die dann doch manchmal zu Ereignissen werden 
im Text. Ok, bisweilen ist es etwas schwierig im Bereich IT die 
Anglizismen rauszuhalten, aber Denglisch ist und bleibt eine schwache 
Kür. Vor allem in einem derartigen Dokument.

Die Beschreibung des Moore-Automaten ist zu kurz und unvollständig.

5.3

"Eine solche Case Struktur ist gut geeignet um kleinere endliche 
Automaten abzubilden. Für das Toasterbeispiel gibt es zwei Merkmale, die 
einem das Leben bei einer solchen Case Struktur schwer machen."

Hä? Erst sagen sie ist gut geeignet und im nächsten Satz ist sie 
problematisch? Komische Welt.
Hier wäre es sinnvoll, erstmal an einem einfachen Beispiel die Sache mit 
case vorzuführen und danach eine andere, leistungsfähigere Methode zu 
demonstrieren.

6.0

C++ auf dem AVR? Naja, Softwerkerdenken. Die Einstiegsschwelle liegt 
damit aber eher hoch, denn C++ ist AFAIK bei weitem nicht so unter 
Nicht-Vollblut Softwerken verbreitet wie C. Und die "monströsen" 
Konstrukte lösen zumindest bei mir als kleinem, dummen Hardwerker schon 
etwas Angst und Unbehangen aus.

Kompletter Sourcecodeanahng ist IMO sinnlos, ein Verweis auf das Archiv 
reicht vollkommen. Schließlich "druckt" kein Mensch den Sourcecode in 
die Doku.

Summa summarum. Das Dokument ist sehr oberflächlich und gehetzt, merkt 
man in jeder Zeile. Ausgereifte, vollständige Erklärungen gibt es nicht.

Der Artikel Statemachine ist um Längen besser. Der Artikel 
Implementierung einer Finite State Machine sollte gelöscht werden, 
ist sowieso nur ein Fragment, davon gibt es im Wiki schon genug. Das 
Dokument hier im Thread kann man ja gnädigerweise im ersten Artikel 
verlinken, "for whom it may concern".

MFG
Falk

P S Vielleicht solle man mal ein gutes Beispiel in BASCOM schreiben, so 
als Gegenstück zum C++ ;-)

Autor: Thomas B. (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry Falk, bei aller möglicherweise berechtigter Kritik, so ist es 
nicht angebracht, die Arbeit von Philipp so runterzumachen! Ich finde es 
toll wenn Forummitgliedern sich die Mühe machen uns 22 Seiten zu solch 
einem Thema verfassen.

Konstruktive Kritik (der Verfasser hat auch darum gebeten) damit das 
Paper besser wird.

Gruß
Thomas

Autor: Philipp K. (philippk) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach dem gemecker einzelner nicht näher spezifizierten Personen möchte 
ich mich nochmals melden:

1. Eigentlich wollte ich den Glaubenskrieg zwischen C/C++ nicht 
entfachen, aber ich kann es mir nun doch nicht verkneifen. C++ ist zwar 
komplizierter, aber nun mal mächtiger und für mein konkretes Beispiel 
geeigneter. Anstatt C++ von Anfang an schlecht zu machen könnte man ja 
auch konkrete Fragen dazu stellen, wenn man ein Stück Code nicht 
versteht.

2. "Auf einem AVR macht C++ keinen Sinn" ist einfach nur blödsinn. Wer 
so etwas behauptet kann entweder kein C++ programmieren oder hat keine 
Ahnung wie ein Compiler eine Hochsprache in Assembler übersetzt.

3. Der Artikel Statemachine sieht wirklich gut aus, und hätte ich 
ihn gekannt hätte ich an manchen Stellen auf ihn verwiesen anstatt die 
Grundlagen selbst zu erklären. Ich denke jedoch beide Artikel haben ihre 
Daseinsberechtigung und keiner von beiden sollte gelöscht werden.

4. Bei schreibfehlern wäre eine Seiten und Zeilennummer sehr hilfreich. 
Ansonsten steht der gesamte Source der Doku zur Verfügung und es steht 
jedem Frei ihn zu verbessern.

5. Nachdem ich mich nun über das gemecker aufgeregt habe möchte ich noch 
allen Danken welche konstruktive Kritik und Lob kund getan haben.


P.S. All jenen die mit meiner Lektüre intellektuell hoffnungslos 
unterfordert sind, empfehle ich die "The Art of Computer Programming" 
von Donald E. Knuth, wobei Denglisch Voraussetzung ist, denn die Bücher 
sind sogar auf Englisch.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Thomas Burkhart (escamoteur)

>Sorry Falk, bei aller möglicherweise berechtigter Kritik, so ist es
>nicht angebracht, die Arbeit von Philipp so runterzumachen!

Was ist für dich runtermachen?

> Ich finde es toll wenn Forummitgliedern sich die Mühe machen uns 22 >Seiten zu 
solch einem Thema verfassen.

Aha, also weil es MASSE ist, ist es automatisch gut?
Nö.

>Konstruktive Kritik (der Verfasser hat auch darum gebeten) damit das
>Paper besser wird.

Na dann lass mal den Dampf aus dem Kessel und lies mein Posting noch 
einmal.

MFG
Falk

Autor: Thomas B. (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk: Über den Ton Deines Postings zu diskutieren ist wie immer müßig.

Abgesehen davon enthält der bisherige Artikel NULL Information zum Thema 
State-Machine in C++ und ohne CASE Anweisung. Insofern ist es auf jeden 
Fall eine sinnvolle Ergänzung und nicht unnötig.

Dein:

>>Das Dokument hier im Thread kann man ja gnädigerweise im ersten Artikel
>>verlinken, "for whom it may concern".


Ist auf jeden Fall unnötig und zählt für mich zum runtermachen.

Mir hat das DOkument heute auf die ein oder anderen Sprünge gebracht.
Gruß
Thomas

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Thomas Burkhart (escamoteur)

>@Falk: Über den Ton Deines Postings zu diskutieren ist wie immer müßig.

Mag sein. Iam who Iam.

>Abgesehen davon enthält der bisherige Artikel NULL Information zum Thema
>State-Machine in C++ und ohne CASE Anweisung.

Sicher, dafür ist er gut verständlich ;-)

> Insofern ist es auf jeden Fall eine sinnvolle Ergänzung

Ok. Dennoch mit diversen inhaltlichen wie formalen Mängeln.

MFG
Falk

Autor: h_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Den "Glaubenskrieg" zwischen C und C++ gibt es sowieso, den muss man 
nicht entfachen :)
Stattdessen wäre es vielleicht sinnvoll ein Beispiel in C++, in C mit 
großem switch-case und in C mit Funktionspointern zu zeigen. Dann kann 
man zugleich Vor- und Nachteile der Sprachen und Methoden aufzeigen 
(Lesbarkeit/Wartbarkeit, belegter Speicher, Geschwindigkeit).
Ich muss jedoch sagen, dass ich Falk in großen Teilen Recht geben muss. 
Um den Artikel aufzuwerten, könntest du nicht nur FSMs sondern auch 
Hierarchische Zustandsautomaten zeigen (HSM). Bei HSMs können Zustände 
selbst Unterzustände haben. Das Ganze dient dazu, die 
Zustandsraumexplosion bei komplizierteren Automaten in den Griff zu 
bekommen. Diese HSMs sind gar nicht so schwer zu implementieren. Man 
bekommt also für ein wenig mehr Aufwand mehr Freiheitsgrade im 
Softwaredesign.

Viele Grüße

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vor langer Zeit habe ich mich auch mit Karnaugh-Diagrammen, Moore- und 
Mealy-Maschinen beschäftigt und auch mal angefangen, eine allgemeine 
objektorientierte Finite-State-Maschine in Pascal zu schreiben, habe das 
aber nicht fortgeführt, weil es immer weniger Aufgabenstellungen dafür 
gab. Heute scheint sich für diese Themen kein Schwein mehr zu 
interessieren, weil kaum noch jemand solche Systeme entwirft, und wenn 
überlässt man alle Feinheiten bei Hardware dem Logikoptimierer der 
Entwurfssoftware oder bei Soft(Firm)Ware dem Optimierer des Compilers.

Ich gebe ehrlich zu, das ich den Artikel garnicht gelesen habe, weil mir 
das Ganze vorkommt wie eine Abhandlung über Probleme einer lange 
vergangenen Zeit, deshalb habe ich ja selbst auch die Beschäftigung 
damit nach und nach aufgegeben. Wenn man heute den Programmierer einer 
Android-App fragt, ob sein Programm mit einer Moore-Maschine arbeitet, 
würde er noch nicht mal drüber lachen können, weil er die Frage garnicht 
versteht.

Oder täusche ich mich da vollkommen und es handelt sich um die Spitze 
der aktuellen Entwicklung? Dann könnte ich ja mein altes Knowhow wieder 
ausgraben.

Gruss Reinhard

Autor: h_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Ansicht nach sind Zustandsautomaten auch heutzutage nicht zu 
ersetzen. Obwohl viele Programme eventgesteuert arbeiten, sind die 
Reaktionen auf viele Events Zustandsabhängig. Oft wird diese 
Kontextabhängigkeit mit globalen Variablen oder Flags gelöst. Warum das 
schlecht ist, muss ich wohl nicht näher ausführen. Die Lösung ist einen 
Zustandsautomaten zu benutzen. Damit wird der Code les- und wartbarer, 
und für den Compiler besser optimierbar, obowohl letzteres auch von der 
Größe des Automaten abhängt. Benutzt man dann noch hierarchische 
Zustansautomaten, wirkt man noch effektiv der Zustandsexplosion 
entgegen.
Nur dass GUI-Programmierer expliziten Zustandsautomaten benutzen, heißt 
weder, dass der Automat nicht doch im Code steckt, noch dass es eine 
gute Praktik ist den Automaten nicht explizit hinzuschreiben. Andersrum 
ist es auch nicht immer notwendig den Zustandsautomaten explizit zu 
programmieren.

Ob es sich nun bei Zustandsautomaten um die Spitze der Technik handelt, 
weiß ich nicht. Bei mir gehört es jedenfalls zur gängigen Praxis.
Wie implementierst du denn ein Protokoll oder ein Benutzerinterface?

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
h_ schrieb:
> Wie implementierst du denn ein Protokoll oder ein Benutzerinterface?

Klar benutze ich Zustandsautomaten, und mir ist das sogar bewusst! 
Wahrscheinlich ist die von mir aufgeworfene Frage eine der Wahrnehmung 
oder des Sprachgebrauchs. Eventbasierte Programme sind eigentlich nichts 
anders als Zustandsautomaten - das System befindet sich in einem 
bestimmten Zustand (auch wenn der nicht numeriert ist und nicht an einer 
Stelle verwaltet wird), und dann tritt ein Event ein, und für 
Zustand+Event gibt es eine definierte Reaktion. So gesehen ist Windows 
ein riesiger Zustandsautomat - aber keiner nennt das so.

Früher mal, in der IT-Steinzeit, wurden Protokolle wie V22bis 
(Modemsteuerung nach internationaler Norm, vor Durchsetzung von 
AT-Befehlen) auch tatsächlich noch als Zustandsautomaten beschrieben, 
das ist heute auch nicht mehr üblich. Soweit ich mich noch erinnern 
kann, wurde in den einführenden Veröffentlichungen zu Windows von 
Microsoft, Peter Norton, Andrew Schulman usw. ganz ausführlich auf die 
Besonderheiten der Ereignissteuerung im Gegensatz zur linearen 
Programmierung hingewiesen, aber nicht auf die Theorie der 
Zustandsautomaten. Irgendwie schon seltsam, seitdem sich dieses 
Paradigma auf breiter Front durchgesetzt hat, wird es nicht mehr 
erwähnt.

Gruss Reinhard

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Admins,

ich beantrage die Löschung des Artikels

http://www.mikrocontroller.net/articles/Implementierung_einer_Finite_State_Machine

Der Beitrag

Beitrag "Re: Artikel über Finite State Machines"

ist im Artikel Statemachine verlinkt.

MfG
Falk

Autor: Philipp K. (philippk) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ich habe nun ein paar Anregungen umgesetz.

* Im Kapile Grundlagen wird für eine genauere Beschreibung auf den 
Artikel Statemachine verwiesen
* Ein paar Schreibfehler korrigiert
* Der Code ist nichtm mehr Anhang abgedruckt

Ich habe die Arbeit von falk noch zu Ende geführt und im Artikel 
Statemachine eine genauere Beschreibung hinzugefügt. (Google Cache sei 
dank)

Autor: Andreas J. (jedel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Phillipp,
super Artikel, habe schon lange nach einen solchen gesucht. Weiter so
Gruss Andreas

Autor: Alfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen Zustandsautomaten kann man wunderbar mit "goto"s realisieren. So 
macht es zumindest das UML-Tool Rhapsody.

http://www-01.ibm.com/software/rational/products/rhapsody/swarchitect/index.html

Autor: Peter Mueller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Philipp,

Aus meiner Erfahrung macht die Impl. von Zustandsdiagrammen per Hand 
recht wenig Sinn. Wieso?

Jede Änderung am Diagramm zieht einige Änderungen am Code nach sich - 
meist hält man das nicht lange durch und das Diagramm ist veraltet. Dies 
wird bei hierarchischen Automaten noch viel kritischer. Und wenn dann 
noch Deep oder Flat Historie ins Spiel kommt wird jede Änderung echt 
lästig. Der Ansatz mit Maschinen zu Modellieren fördert aber geradezu 
dazu auf iterativ zu arbeiten.

Aus Zustandsautomaten kann man vollständig ablauffähigen Code erzeugen. 
Das ist der Unterschied zu vielen anderen UML Diagrammen, die wirklich 
nur als Doku dienen.

Vor dem Generieren können umfangreiche Modellchecks gemacht werden. 
Bsp.: Ist ein init State vorhanden, hat jede Transition einen Trigger, 
gibt es tote Enden im Diagramm, gibt es Zweideutigkeiten ...

Tools zur Generierung erlauben oft auch die Simulation. Damit können 
viele Probleme durch "Spielen mit der Maschine" gefunden werden.

Dann kommt da noch das Thema Trace Code zu erzeugen.

Usw.

Dem Aspekt Generierung würde ich also ein eigenes Kapitel widmen.

Gruß,
Peter Mueller


P.S. Ich will nicht verhehlen, dass ich ein entsprechendes Tool unter 
www.sinelabore.com anbiete. Im Handbuch wird ein einfacher 
Mikrowellenofen als Beispiel verwendet und daraus Code erzeugt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.