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
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
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
Verzeihung Mr.X, aber mir entzieht sich der Sinn und Zweck Deiner Antwort...
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
@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ß
gibt es schon eine komplettlösung von diesem menü? oder dauert es noch?
Gibt es bereits einen Artikelrumpf, bzw. einen Link? Gruß Steffen.
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
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:
1 | while(1) |
2 | {
|
3 | switch(STATE) |
4 | {
|
5 | MAIN
|
6 | OPTIONS
|
7 | ERROR
|
8 | ...
|
9 | }
|
10 | }
|
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.
> 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
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
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.