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
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..
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...
Hallo Philipp, auf Deiner Tastatur scheint die Komma-Taste teilweise defekt zu sein. Oder liegts am Finger, oder an der Ansteuerung desselben?
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...
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.
Ich habe hier mal die aktuelle Version inklusive der Sourcen. Im Wiki existiert jetzt auch ein Artikel dazu [[Implementierung einer Finite State Machine]]
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
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...
Kan asta schrieb: > aber ich hätte ein anderes Thema gewählt... Dann nicht blöd schnacken, MACHEN!!!
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...
Naja das Thema muss ja nicht jedem gefallen... Ich finde soetwas schon spannend und interessant. Würde ich geren in der Embedded Journal lesen.
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 ...
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
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...
@ Thomas Burkhart (escamoteur) >Oder habe ich dann einen Fehler in meiner State machine wenn das >notwendig ist? Ja.
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
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
@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
@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
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++ ;-)
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
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.
@ 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
@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
@ 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
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
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
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?
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
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
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)
Hallo Phillipp, super Artikel, habe schon lange nach einen solchen gesucht. Weiter so Gruss Andreas
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.