FSM-Programmierung ???

hallo zusammen,
ich hab da ein proprietäres, serielles protokoll auzuwerten. Der 1.Lösungsansatz über if, then, else... wird sehr unübersichtlich und ist in keinster weise wartungs/änderungsfreundlich. ein zustandsautomat scheint mir da die professionellere lösung zu sein. da scheint es (wie so manche diskussion ergab) aber mehrere realisierungswege zu geben. ein erster ansatz über eine tabelle mit funktionspointern funktioniert zwar, aber selbst da gestalten sich änderungen (z.B. wenn die reihenfolge der zustände geändert werden muß) noch zu ziemlich aufwändig.

die suche in den faq's als auch in google nach einem eleganten konzept wie man state machines effizient realisiert führte zu keinem befriedigenden ergebnis.
nun die bitte an euch. hat da einer eine idee, bzw. einen sinnvollen, verwertbaren hinweis (literatur, url, beispiel, etc).

für brauchbare antworten schon mal ein danke im voraus.
chris

pointercrash**

Schau 'mal bei Sourceforge nach:

** Project: FSMGenerator
** Module:
** File: README
** Date: 2002.08.01
** Author: Pavel Bekkerman (chpavel@tx.technion.ac.il)
** Copyright: Copyright (C) 2002, 2003 Pavel Bekkerman

Ich persönlich codiere zwar lieber per Hand, aber es soll ja Leute geben, die auf gescriptetes C stehen ...

schon mal danke für den tip

aber auch zum verständnis, ich suche hier kein "halbzeug" oder eine maske wo ich nur einsetzen brauche. codieren möchte ich das schon auch selber. meine frage ist, wie macht man sowas am vernünftigsten?
das mit dieser SW zu decodierende protokoll lebt, d.h. der code sollte so selbstdokumentierend wie möglich sein, damit ich (oder ein anderer) das auch nach einigen monaten wieder rasch anpassen kann.

chris

pointercrash() schrieb:

Schau 'mal bei Sourceforge nach:

** Project: FSMGenerator
** Module:
** File: README
** Date: 2002.08.01
** Author: Pavel Bekkerman (chpavel@tx.technion.ac.il)
** Copyright: Copyright (C) 2002, 2003 Pavel Bekkerman

Ich persönlich codiere zwar lieber per Hand, aber es soll ja Leute geben, die auf gescriptetes C stehen ...

pointercrash**

Der Generator führt eine neue Abstraktionsebene ein und bastelt daraus das Programm- Rohgerüst.
Aus Zustand und Eingängen werden Folgezustand und Übergangsaufrufe generiert. Welche Funktionen man dabei aufrufen läßt, bleibt Dir selbst überlassen. Aus dem FSM- Script kriegt man halt ein include.
Wie bei allen Generatoren arbeitet man eine Ebene "darüber" und muß nur das Script warten und dokumentieren, die ausgespuckte Source ist wie immer halt einfach häßlich.

Wenn man damit leben kann - just use it!

Blackbird

"... protokoll ... rasch anpassen ..."

Das eine widerspricht dem anderen :p

Ein Weg (einer von vielen) geht so:

1. Eine grafische Darstellung in SDL-Syntax erstellen, die das ganze Protokoll (beide Seiten) darstellt. Protokoll "per Hand" durchspielen.
2. Eine Tabelle schreiben (Text), die als Spalten die State und als Zeilen die Events enthält. in alle relevanten Kreuzungspunkte werden die passenden "Handlungen" eingetragen.
3. In C/C++ ein Funktionspointer-Array erstellen, welches ein Abbild der Tabelle ist. Einen Datenblock definieren, der im einfachsten Fall nur den aktuellen State speichert. Eine Event-Verteiler-Funktion schreiben, die alle ankommenden Events auf das Pointer-Array (hier ist der State gefragt!) verteilt.

Ob das ganze per Hand oder Generator geschieht, ist vollkommen egal.

Änderungen im Protokoll werden nicht "on-the-fly", sondern in der gleichen Reihenfolge (1., 2. und 3.) durchgezogen - sonst ist das Chaos perfekt!

Blackbird

hi,
und nochmal danke für die prompte unterstützung.
sourceforge ist gut, da gibts wohl mehrere möglichkeiten. werd das mal durchwühlen um zu sehen wie sich's mit sowas leben läßt.

gruß aus BY
chris

pointercrash() schrieb:

Der Generator führt eine neue Abstraktionsebene ein und bastelt daraus das Programm- Rohgerüst.
Aus Zustand und Eingängen werden Folgezustand und Übergangsaufrufe generiert. Welche Funktionen man dabei aufrufen läßt, bleibt Dir selbst überlassen. Aus dem FSM- Script kriegt man halt ein include.
Wie bei allen Generatoren arbeitet man eine Ebene "darüber" und muß nur das Script warten und dokumentieren, die ausgespuckte Source ist wie immer halt einfach häßlich.

Wenn man damit leben kann - just use it!

hi,
na so ungefähr auf dem weg (punkt3) bin ich ja schon. nur die beiden ersten positionen sind bei mir chaotischer, deshalb danke für den tip auf eine bessere struktur. muß mal ein paar änderungen durchspielen um einen überblick über den aufwand zu erhalten.
herzlichen dank für die rasche unterstützung.

gruß
chris

Blackbird schrieb:

"... protokoll ... rasch anpassen ..."

Das eine widerspricht dem anderen :p

Ein Weg (einer von vielen) geht so:

1. Eine grafische Darstellung in SDL-Syntax erstellen, die das ganze Protokoll (beide Seiten) darstellt. Protokoll "per Hand" durchspielen.
2. Eine Tabelle schreiben (Text), die als Spalten die State und als Zeilen die Events enthält. in alle relevanten Kreuzungspunkte werden die passenden "Handlungen" eingetragen.
3. In C/C++ ein Funktionspointer-Array erstellen, welches ein Abbild der Tabelle ist. Einen Datenblock definieren, der im einfachsten Fall nur den aktuellen State speichert. Eine Event-Verteiler-Funktion schreiben, die alle ankommenden Events auf das Pointer-Array (hier ist der State gefragt!) verteilt.

Ob das ganze per Hand oder Generator geschieht, ist vollkommen egal.

Änderungen im Protokoll werden nicht "on-the-fly", sondern in der gleichen Reihenfolge (1., 2. und 3.) durchgezogen - sonst ist das Chaos perfekt!

Blackbird