Softkeys und Statemachine

[Gastlos (Gast)]

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?

[Gastlos (Gast)]

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.

[klaus (Gast)]

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.

[Oliver (Gast)]

>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

[Gastlos (Gast)]

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.

[Claudio F. (zunge)]

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 !

[G. O. (aminox86)]

Hier noch als Anregung für hartgesottene C-Programmierer: tinykon
(Menüsystem auf Basis einer tabellengesteuerten Zustandsmaschine)
mfg

[Gastlos (Gast)]

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!

[Gastlos (Gast)]

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)?