Mithilfe bei Artikel über LCD + Menü mittels State Machine

[Julien (Gast)]

Hallo,

ich möchte die leidige Frage nach einem LCD Menü nochmals aufgreifen.
Ich weiß es gibt hier schon ein paar Codeschnipsel und auch diverse 
Forenbeiträge.

Ich habe mich bisher durch diese Artikel durchgearbeitet und auch im 
Internet viel recheriert. Leider findet sich kein komplettes Tutorial 
das den Aufbau die Funktionen und die Realisierung abdeckt.

Ich möchte zum einen für mein eigenes Projekt Erfahrungen sammel und 
anschließend daraus einen LCD Menü Artikel hier für die Artikelsammlung 
schreiben.

Aus diesem Grund würde ich mich freuen wenn erfahrene User als auch 
kreative Köpfe hier ihr Wissen kundtun.

Meine Überlegungen sehen wie folgt aus:

Ein AVR wird mit einem 4x20 LCD und 5 Tastern (UP, DOWN, LEFT, RIGHT, 
ENTER) bestückt.
Damit das Rad nicht neu erfunden wird schlage ich die Entprellroutine 
von Peter Dannegger aus dem Tutorial vor und der LCD Lib von Peter 
Fleury.

Des weiteren soll eine STATE MACHINE für das Menü eingerichtet werden. 
Ich denke dies ist eine sinnvolle Methode um das Menü später an 
individuelle Vorlieben anzupassen ohne das die Übersichtlichkeit 
verloren geht.

Aus eigener Erfahrung habe ich bisher nur erfolgreich mit der LCD Lib 
und der Tastenentprellung gearbeitet. Hierzu gibt es gute 
Dokumentationen.

Die Einrichtung einer STATE MACHINE blieb bislang erfolglos.
Mir ist der grobe Aufbau klar jedoch bring ich die einzelnen 
Codefragmente nicht richtig zusammen.
Hier bedarf es Hilfe!

Ich habe als Literatur auch folgenden Artikel gefunden.
http://www.humerboard.at/doku/sb8/uc5.pdf

Ziele des zu erstellenden Artikels:
- einzelne Bausteine erklären (LCD, TASTER, MENÜ)
- Quellcode zum nachbau aufbereiten

Wem jetzt noch was einfällt darf sich gerne melden.
Ich hoffe dieser Artikel findet regen Zuspruch.

Gruß Julien

[Blackbird (Gast)]

Der "Gehirnschmalz" wird ja nicht für die Programmierung an sich 
benötigt, sondern für die in sich schlüssige und widerspruchsfreie 
Darstellung des Menübaumes und seines Durchwanderns benötigt.
Daran hapert es doch bei den meisten Anwendern.
Ob dann dieser Baum und sein Handling per switch-case, if-else, struct 
oder pointer-field realisiert wird, ist so gut wie egal.

Was auch gerne übersehen wird: keine Menü-Struktur ist von vornherein 
fertig designd. Jede Änderung erfordert aber nicht nur Veränderungen in 
den Programmzeilen, sondern VORHER eine Anpassung des Baumes (auf 
Papier, als Excel, UML, oder sonstwas) und DANACH erst die Umsetzung in 
den Programmcode. Sonst wird es ein programmiertes Chaos.

Den Ablauf: 1. Design und 2. Code-Erstellung/Änderung kann man mit einem 
(auch selbstgeschriebenen) Template-Generator recht fehlerfrei 
hinkriegen.

Das sollte schon alles in dem Artikel berücksichtigt werden, aber alles 
hier in einem Artikel zusammenfassen halte ich für sehr anspruchsvoll.

Blackbird

[Mr.X (Gast)]

Ich habe innerhalb von 2 Wochen ein Menü mit state machine und Event 
Handling entworfen und implementiert. Das ganze ist insoweit modular, 
als das es sich einfach durch schicken von Events an den Eventhandler 
einbinden lässt.

Somit wird nicht nur das UI-Menu gehandelt, sondern auch auf 
aussergewöhnliche Events wie z.B. Fehlermeldungen reagiert.

Klappt prima :-)

Ist am Anfang ne fiese Sache das aufzusetzen, aber danach sehr einfach 
erweiterbar.


Leider ist das ganze closed source. :-(

Schöne Grüße und viel Spass

[Christoph S. (mcseven)]

Verzeihung Mr.X, aber mir entzieht sich der Sinn und Zweck Deiner 
Antwort...

[Mr.X (Gast)]

Der Sinn ist, dem Julien und anderen noch den Tip zu geben, nicht nur 
eine statemachine zu bauen, sondern gleich noch einen eventhandler 
einzubeziehen, damit Dinge wie Fehlermeldungen und dergleichen einfacher 
integriert werden können und die Portierung des Menüs auf verschiedene 
Anwendungen zu vereinfachen.


Gruß
Mr.X

[Julien (Gast)]

@Blackbird
Nun es ist schon richtig, das es zunächst hauptsächlich um eine 
brauchbare Menüstruktur geht. Hierbei mit Blick auf die Erweiterbarkeit. 
Ebenfalls spielt es hierbei noch keine Rolle wie letztendlich das in 
Code umgesetzt wird.

Ich dachte jedoch an eine STATE MACHINE um einfach die Erweiterbarkeit 
zu gewährleisten. Dadurch dass im Grunde die kompletten Operationen in 2 
Tabellen festgehalten sind.

Ich habe versucht den Artikel einen groben Rahmen zu geben, jedoch ist 
es möglich der Menü-Struktur einen eigenen Artikel zu widmen.
Hierbei bin ich über jeden Vorschlag dankbar.

Aus diesem Grund würde ich erstmal mit 2 Teilen anfangen:
1. Menüstruktur
2. Aufbau und Struktur der State Machine für ein Menü


Wenn Du dazu schon konkrete Texte oder Vorschläge aus eigenen 
Erfahrungen hast dann würde ich mich freuen wenn diese hier im Forum 
niedergeschrieben werden.


@Mr. X
nun dass ist ja sehr erfreulich dass Du es in 2 Wochen geschafft hast 
ein Menü zu erstellen.
Da es sich bei Dir um die angesprochene State Machine handelt, wäre es 
dir evtl. möglich hier den oben genannten "Punkt 2" mit leben zu füllen.

Ich möchte jetzt nicht deinen CLOSED CODE sehen, denn der ist ja 
schließlich "closed", aber die Idee und die Grundstruktur lässt sich 
sicher hier publizieren ohne dass dein Code nachgebaut werden kann.


Da ich selber noch recht wenig mit Menüs gemacht habe bin ich aus 
programmtechnischer Seite noch auf Hilfe angewiesen, quasi als 
Startenergie.



Darum nochmal, einfach hier in den Thred Codeschnippsel und Infos 
reinpacken, die dann gemeinsam zu einem brauchbaren Artikel werden.

Gruß

[art (Gast)]

gibt es schon eine komplettlösung von diesem menü?
oder dauert es noch?

[Steffen (Gast)]

Gibt es bereits einen Artikelrumpf, bzw. einen Link?
Gruß
Steffen.

[Sebastian B. (mircobolle)]

Hallo,

ich habe im Rahmen meiner Master-Thesis auch ein Menü auf einem
2x16 Display entwickelt.

Gesteuert wird das Menü über 2 Tasten (Ok, Back) und einen Dreh-Encoder 
(für UP and DOWN).

Ich würde auch meine Hilfe für diesen Artikel anbieten.

Mein Menü ist mit Sicherheit nicht perfekt, aber ich habe einige 
Erfahrungen gesammelt. Ich würde jetzt auch einige Dinge anders machen.

Kurz zu meinem Design:

Der Menü-Baum ist in einer 2D Tabelle definiert.

Ich habe eine Routine, die die aktuellen 2 Menü-Einträge auf dem Display 
ausgibt. Beim drehen des Dreh-Encoders (UP/DOWN) wird ein entsprechendes 
Event an die Routine geleitet und die Ansicht aktualisiert. Das Menü 
"rotiert" wenn der letzte Menü Eintrag oder der erste überschritten 
wurde.

Ich habe eine weitere Routine die die Events (OK / BACK) auswertet. Dies 
ist für den Wechsel innerhalb der Menü-Ebenen notwendig (also das auf- 
und ab-steigen im Menü-Baum).

Der Kern des Menüs ist eine State-Machine, die je nach Menü-Zustand 
anders reagiert. Z.b. Werte anzeigen  Werte eingaben entgegen nehmen  
Bedienung sperren / Menü-Navigation

Hier bei youtube habe ich ein Video reingestellt, welches die Anwendung 
des Menüs darstellt.

http://www.youtube.com/watch?v=GhUI7uQmt_c

In welcher Form kann ich mit bei dem Artikel beteiligen?

MFG

[Jimmy (Gast)]

Hi,
Ich musste auch mehrere Menus in ein Projekt integrieren. Ohne groß zu 
recherchieren bin ich auch auf eine STATE MACHINE gekommen. Allerdings 
habe ich einen 130x170 Display zur Verfügung.

Die Struktur ist folgende:

Aus dem Hauptmenü (MAIN) wird der Button "Options" betätigt. Ich setze 
STATE auf z.B. MODE_OPTIONS und benutze vordefinierte Funktion "mal mir 
options".

Nun läuft die "while(1)" schleife von vorn und führt den neuen STATE 
aus.
Im jeweiligen STATE werden auch die Tasten abgefragt (switch), wurde nix 
betätigt, kann man auch Code im "default" des switch cases einfach 
ausführen.

Also ungefähr so:

while(1)
{
    switch(STATE)
    {
     MAIN
     OPTIONS
     ERROR
     ...
    }
}

Speziell in Menüs (wie Options) verwende ich 2 Spalten: Einträge und 
Werte und navigiere jeweils mit UP/DOWN durch die Einträge, wechsle mit 
RIGHT auf Werte und mit LINKS zurück zu Einträgen. Wenn Werte aktiv 
sind, verändern UP/DOWN diese.

Das ganze ist open-source, schätze ich, wenn also Interesse besteht - 
nachfragen. Obwohl das Ganze eher nicht sexy ist. Ich würd auch gern von 
Mr. X hören wie er es mit Events gemacht hat.

[Sebastian B. (mircobolle)]

> Das ganze ist open-source, schätze ich, wenn also Interesse besteht -
> nachfragen. Obwohl das Ganze eher nicht sexy ist. Ich würd auch gern von
> Mr. X hören wie er es mit Events gemacht hat.

Naja, was heißt schon "Event-Handler". Auf einem OOP System würde ich 
darunter das Observer-Pattern verstehen (siehe Software-Pattern).

Aber auf einem Mikrocontroller-System mit Modulen und ohne RTE läuft das 
meiner Meinung nach alles ein bisschen unspektakulärer, weil 
performanter ab.

Meiner Meinung nach gibt es nur folgende EVENTS, die für ein Menü von 
Bedeutung sind:

- Direkte Events (Bedienung durch Steuerelemente, Taster, Encoder usw.)
- Externe Events (Moduswechsel des Systems, dies kann einfach über eine 
Menü-Schnittstelle und einen State Wechsel innerhalb des Menü-Moduls 
realisiert werden).

die externen Schnittstellen wären z.b. "Sperre die Menü-Bedienung und 
übergebe Steuerung des Displays an Modul Xy"
oder
"entsperre Menü und die Steuerung wird wieder über Menü-Steuerung 
übernommen"

sollte das ganze über ein "echtes" Observer-Pattern oder Event-Pattern 
gelöst sein, würde mich das ganze natürlich auch interessieren.

sprich, dafür würde eine entsprechende Abstraktions-Ebene mit flexiblen 
Funktions-Pointer benötigt werden, die ein solches Event-Handling 
ermöglichen. Dies ist aber nicht gerade das gelbe vom Ei, wenn es um 
Laufzeit geht.

Ich benutzte für meine Menü-Steuerung keinen Funktionsaufruf aus der 
Main While()-Schleife. Bei mir läuft alles deterministisch über 
Task-Zeiten aus der RTC-ISR meines Systems.

Mein Menü-Task läuft z.b. mit einer Periodendauer von 50 ms.

MFG

[Sebastian B. (mircobolle)]

Nochmal ein Nachtrag zu diesem Event-Handler:

@Mr.X:
Kann man sich das ganze modular, so wie in dem angehängten Komponenten 
Diagramm vorstellen?

Eine andere Sache die für den Aufbau des Menüs noch interessant wäre:

> Wie verknüpft ihr eine spezielle Funktion hinter einem Menü-Punkt mit der 
Menü-Struktur?

Optionen:
a) In der Menü-Struktur befindet sich ein Funktionspointer (meiner 
Meinung nach wird hier die Bindung zwischen Menü und anderen Modulen zu 
stark)

b) Wird eine Funktion im Menü erreicht wird in eine spezielle Funktion 
im Menü-Modul gesprungen, die eine ID in der Menü-Struktur in einem 
switch-case auswertet und daraufhin die entsprechende Funktion aufruft.
(Hier finde ich die Kopplung zwischen Menü-Modul und anderen Modulen 
weniger stark vorhanden)

Was ist eure Meinung? Welche Kopplungsmethode ist besser?

Ganz gefällt mir das ganze aber auch nicht... habt ihr eine Idee wie man 
Menü und die Funktionen, welche das Menü anspricht, mehr abstrahieren 
könnte???

MFG