Butterfly state-machine vorbildlich? Wer erläutert Funktionsweise?

Die Funktionen in der Beispielanwendung blockieren nicht (bis auf die 
Hardware-Test-Funktionen, die aber nicht über normale Eingabe gestartet 
werden können). Einfach mal in die Funktionen reinschauen, sind immer 
nach dem gleichen Prinzip aufgebaut:

- Parameter Input ist die Joystickeingabe ("stimulus" heißt das glaub 
ich)
- eine statische Variable enter, in den Beispielen meist mit 1 
initialisiert, dient dazu, den ersten Aufruf der Funktion zu erkennen.
- Prüfung auf enter<>0, wenn ja Initialisierungen durchführen enter auf 
0
- Dann Fallunterscheidung auf Input und entsprechende Aktionen ausführen
- Rückgabe ist der State-ID. Falls dieser nicht mit dem aktuellen 
Zustand übereinstimmt, enter auf 1 setzten, damit beim nächsten Aufruf 
der Funktion die notwendigen Initialisierungen wieder durchgeführt 
werden
- Die Hauptschleife in main() kümmert sich um die Auswertung des 
Rückgabewertes, also des Status-ID. Stimmt dieser nicht mit dem vor dem 
Aufruf der Funktion überein, wird anhand des neuen IDs in der 
Zustandsliste gesucht, die Anzeige aktualisiert und gegebenenfalls in 
die State-Funktion per Funktion-Pointer gesprungen (von "Bastler" ja 
schon beschrieben).

Wenn man sich an das Schema hält blockieren die Funktionen nicht. Soll 
auch so sein, damit z.B. die Aktivierung der Stromsparfunktion 
funktioniert (vgl. Code in main.c der Atmel Beispielanwendung (oder 
meinem GNU-Port davon).

Betr. der Frage im Topic von "Bastler" vom Juni 08: Ich weiss nicht, ob 
das vorbildlich ist, finde die Vorgehensweise aber recht brauchbar und 
nicht allzu unübersichtlich. Abgesehen von meinen etwas wirr aussehenden 
Anpassungen an "progmem" für avr-gcc/avr-libc, könnte man vielleich mit 
ein paar Macros netter aussehen lassen. Die erste Portierung des 
Beispielcodes von Atmel für IAR nach GNU war seinerzeit mein erster 
Kontakt mit avr-gcc/avr-libc und ein Sprung in ziemlich kaltes Wasser, 
aber auch sehr viel dabei gelernt.