Man denke an ein Handy: Eine handvoll Softkeys, deren Beschriftungen und Funktionen sich naturgemäss ändern. Der Zustand der Tasten wird durch den Kontext (Menü, Telefonnummer eingeben) bestimmt. Ein solches Verhalten möchte ich mittels einer tabellenbasierten state machine realisieren (virtual? fsm), sofern es keine geeignetere Methode gibt. Ich habe jedoch Schwierigkeit, die Zustände geeignet zu definieren, da die Softkeys einen Verbund bilden. Wenn ich den Verbund als Zustand betrachte, ergeben sich möglicherweise sehr viele Verbundzustände (durch n Tasten bestimmt). Alternativ könnte man jede Taste separat handhaben, die Zustandsänderung der möglicherweise abhängigen Tasten müsste dann in der Funktion erfolgen. Wie entwickelt man soetwas? Sieht jemand den 'richtigen' Ansatz?
Eigentlich ist es ja noch komplizierter, da die letztenendes ausgeführte Funktion nicht nur von der Tastenbelegung, sondern auch vom aktiven Element abhängt. Im Menü wird z.B. der nächste Eintrag ausgewählt, bei der Telefonnummer die Ziffer verstellt. Vielleicht ist eine statemachine doch nicht das Mittel der Wahl.
Man könnte eine Tabelle erzeugen, welche die Zuordnung zwischen physikalischer Taste und dem jeweiligen Event (der aktuellen logischen Bedeutung) enthält. Wird eine Taste gedrückt, wird die State Machine mit dem aus der Tabelle entnommenen Event getriggert. Erfolgt ein Zustandswechsel in der State Machine bei welchem sich die logischen Bedeutungen der Tasten ändern, wird die Tabelle entsprechend geupdated.
>Vielleicht ist eine statemachine doch nicht das Mittel der Wahl.
Das ist sie schon, aber nicht für alle Ebenen der Eingabe.
Zifferneingabe bei der Telefonnumerneingabe gehört vermutlich nicht
dazu.
Und "Verbünde" gibt es da auch nicht. Du bist immer in genau einem
Zustand, und dazu gibt es eine (zustandsabhängige) Menge von
zustandsverändernden Ereignissen (z.B. Betätigung eines Softkeys). Jedes
zustandsverändernde Ereignis führt in genau einen anderen Zustand.
Und ja, da können schon ein paar Zustände zusammenkommen.
Ein Beispiel für eine Zustandsmachine gibt es in der Firmware zum
Atmel-Butterfly.
Oliver
Danke soweit. Mit dem Verbund meinte ich die Aufteilung des Zustands des Gesamtsystems z.B. in "Zustand Menü" und "Zustand Softkeys". Sonst wäre ja eine unverhältnismässig grosse Tabelle mit Zuständen erforderlich, mit redundanten Einträgen.
Hallo da lass ichs mir nicht nehmen auf die hirarchischen State-Machins ala Quantum-Framework zu verweisen. es gibt ein super buch dazu, mit beispielen von solchen hirarchischen SM wie du sie andekst. siehe: http://www.state-machine.com/ gibts für private für lau ... gruss Claudio ps: für viele uC-Architekturen gibts bereits einen download auf der homepage !
Hier noch als Anregung für hartgesottene C-Programmierer: tinykon (Menüsystem auf Basis einer tabellengesteuerten Zustandsmaschine) mfg
Ich möchte das nochmal ansprechen, da mir "die" Lösung leider nicht eingefallen ist. Für meine Hauptnavigation ("Bildschirme") habe ich nun eine tabellenbasierte Zustandsmaschine umgesetzt, d.h. ich suche nach einer Eingabe die Zordnung zum gegenwärtigen Zustands, aus den beiden Größen ergibt sich der nächste Zustand, dem wiederum eine Funktion (screen_foo()) zugeordnet ist. Die Tastenbelegung für KEY1..KEYN ist in einem Array abgelegt, über das die Beschriftung und der keycode (= event) ermittelt werden. Die Funktion der "Bildschirme" (z.B. das Menü) muss ebenfalls über eine Eingabe getriggert werden. Natürlich ist abstrakt immer nur ein Zustand möglich, aber in meinem Verständnis wäre eine Tabelle mit allen Zuständen zu komplex (und nicht effizient, da sich die Suchzeit vervielfacht). Ausserdem wird die Darstellung der Zustände unübersichtlich: Zustand: BildschirmEins + ElementDreiAusgewählt (+ ElementTypTelefonummer) + Taste1MitFunktionBar + Taste2MitFunktionFoo + Taste3MitFunktionEnter + Taste4MitFunktionCancel BildschirmZwei + ... An der Stelle wäre es doch sinnvoll, wenn man verschiedene Tastenlayouts einführt, die für bestimmte Zustände gelten. D.h. es bedarf einer Zuordnung Zustand<->Layout und beim Übergang ggf. eine Aktualisierung der Tasten. Aber an welcher Stelle geschieht das? Ist es Aufgabe der Übergangsfunktion? Erfolgt es im Event-Handler (state+event->state_next)? Wie dann untergeordnete Zustände (Telefonbuch->Gastlos ausgewählt->Gastlos bearbeiten->...)gehandhabt werden - keine Ahnung. Vielleicht ist an der Stelle eine verabschiedung von der Zustandstabelle nötig, und die Bildschirme bzw. darunterliegende Funktionen bringen ihre eigenen Zustände mit? Bin gespannt auf eure Ideen!
Noch was Naheliegendes: Sämtliche Eingabeevents werden durch die Statemachine durchgereicht (überflüssiger overhead?) und so auch bei keinem Zustandswechsel an die aktuelle "Bildschirm"-Funktionen durchgereicht. Woher weiß diese aber, dass kein Zustandswechsel stattgefunden hat (und demnach nur Teilbereiche aktualisiert werden müssen)?
Bitte 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.