Forum: Mikrocontroller und Digitale Elektronik Konzept Menu und Schnittstelle


von Martin (Gast)


Lesenswert?

Hallo Leute!


Ich habe mich in letzter Zeit etwas mit µC-Programmierung 
auseinandergesetzt und dazu so einfache Bausteine, wie DS1621 
angesteuert und hierfür auch Libraries entwickelt.

Wenn man ein Gerät entwickelt z.B. mit Display und Taster, dann gibt es 
mehrere Möglichkeiten, mit der Umwelt in Kontakt zu treten.
Variante 1: Entweder das Gerät ist Stand-Alone. Der Benutzer kann sich 
mittels Drehtaster durch Menus bewegen, die über das Display angezeigt 
werden
oder
Variante 2: Das Gerät kommuntziert mit einem PC, welcher dem Gerät die 
Befehle erteilt und dieses dann entsprechend handelt. Diese Variante ist 
meiner Meinung nach am einfachsten zu implementieren.
oder
Variante 1 und Variante 2 kombiniert.

Meiner Meinung nach ist das Scrollen durch ein Menu (Variante 1) mittels 
Drehtaster eine relativ komplexe Angelegenheit, weil das Menu auf 
verschiedene Statuszustände auch verschieden reagieren soll. Wenn sich 
der benutzer in einem Untermenu befindet, dann soll er mit "CLR" ins 
Hauptmenu gelangen können, aber wenn er im Hauptmenu ist, dann soll bei 
"CLR" nicht passieren. Wann schaltet sich der Cursor ein oder aus? Wann 
kann man Einstellungen ändern und wann nicht? Zudem soll das Menu 
einfach zu erweitern sein und entsprechende Eingabefehler des Benutzers 
müssen abgefangen werden und das ganze Konzept sollte zudem auch noch 
beherrschbar bleiben.

Wenn man vor hat Variante 1 und Variante 2 zu implementieren, dann 
müsste es doch möglich sein, eine einheitliche Schnittstelle zu 
entwicklen, welcher es egal ist, ob ein Befehl vom PC kommt oder vom 
Menu ausgewählt wird. Wenn so eine allgemeine Schnittstelle vorliegt ist 
es bei einem späteren Projekt relativ einfach, nach diesem 
vorgefertigten Grundgerüst die entsprechende Schnittstelle mit dem PC 
oder dem Menu zu verbinden und das Ganze Projekt ist dadurch modular 
aufgebaut und für den Programmierer überschaubar.

1. Ich benötige ein gutes Konzept, welches mir die Implementierung eines 
Menus ermöglicht, welches dann einfach zu erweitern ist, übersichtlich 
ist und auch durch entsprechende Funktionen einfach steuerbar ist. So 
ein Menu ist fast immer mit einem Display gekoppelt.

2. Ich benötige ein gutes Konzept für eine Schnittstelle, die es erlaubt 
entsprechende Menu-Befehle oder auch PC-Befehle zu verarbeiten.


Hat jemand von euch in diesem Bereich Erfahrungen und kann mir Tipps 
geben, wie man am besten an so eine Sache rangeht?


Danke für eure Hilfe.

Tschüss

Martin

von Martin S. (mar6306011)


Lesenswert?

Geht das mit Strukturen?

von Florian M. (flomll)


Lesenswert?

Ich habe gerade das selbe Vorhaben gestartet und versuche mich grad mit 
Strukturen und void *

Ich denke da an eine doppel verkettet Liste. Wenn ich Ergebnisse habe, 
dann werde ich sie natürlich so bald wie möglich posten.

Lg

von Michael B. (bubi)


Lesenswert?

Mein Ansatz wäre ein RTOS als Basis zu verwenden...
Aufbau wäre ca so.

LCD Task .... alle 25ms -> unkritsch -> arbeitet die Eingaben vom 
Benutzer mittels einer Messagequeue ab.
Eingabe Task Tastatur  ... alle ~10ms -> relativ kritisch, da es eine 
"flüssige" Bedienung sein soll -> Übergibt Eingaben einer Queue für den 
LCD Task und einen fürs abarbeiten.
Eingabe Task PC Schnittstelle ... alle ~100ms -> unkritisch -> Buffer 
muss halt groß genug sein, übergibt seine "Befehle" der Queue für 
Befehle abarbeiten
Befehls Task -> Rest der Zeit -> Arbeitet die Befehle nach der Reihe 
nach ab wie sie in der Queue gelandet sind und übergibt es wiederum der 
PC-Schnittstelle (Task über Queue) oder dem LCD was angezeigt werden 
soll.

Vorteile sehe ich in einer guten Gliederung und aufteilung.
Du kannst die Schnittstellen auftrennen, nacheinander entwicklen und 
erweitern unabhängig von einander. Es bleibt realtiv übersichtlich. Und 
du kannst dich viel mit Prioritäten und Zeiten rumspielen bist du dort 
bist wo du hinwillst.

In einem while(1) als etwas zyklischen hast du immer das Problem. Wenn 
du etwas ändern willst oder erweitern das es dir das komplette System 
zerhaut. Sei es vom Timing oder von den Möglichkeiten.
Ich will damit nicht sagen das es anders nicht ginge, aber in so einem 
System spielt je nach Komplexität ein "OS" seine vollen Vorteile aus.

von Karl H. (kbuchegg)


Lesenswert?

Ich denke einer der Schlüsselpunkte ist die strikte Trennung von GUI und 
Auswertung der Befehle.

Sieh dir bsp. Windows an (klassisches Windows)
Wenn am GUI irgendetwas passiert, dann wird nie direkt eine bestimmte 
Funktionalität aufgerufen, sondern Windows schickt eine 'Message'. 
Message ist dabei ein hochtrabender Begriff dafür, dass Windows einfach 
nur einen Code gemeinsam mit 2 optionalen Parametern generiert und diese 
'Message' in eine Queue stellt. Dein Programm hat dann eine Message-Loop 
in der sie in dieser Queue nachsieht, ob was da ist und wenn ja, dann 
diese angeforderte Funktion ausführt.
Wie die Message in die Queue kommt, ist für dein Programm zweitrangig. 
Ob das jetzt geschieht, weil der Benutzer mit der Maus irgendwo 
hinklickt oder weil ein Menüpunkt ausgewählt wurde oder aber weil 
vielleicht von einem anderen Programm eine Message in deine Queue 
gestellt wurde, hat dein Programm nicht zu interessieren. In deiner 
Message Queue steht einfach nur: "Funktion-Datei-Laden" angefordert und 
nur darauf reagiert deine Message-Loop.

Übertragen auf dein Problem:
Dein eigentliches Programm könnte ähnlich aufgebaut sein. Bestimmte 
Ereignisse in einer Input-Queue triggern Aktionen.

Der PC wird über eine normale UART angebunden, die zb 
interrupt-getrieben funktionier. Im Interrupt wird ein Kommando (zb in 
Form einer Befehlszeile) sukzessive aufgebaut. Ist das Kommando 
vollständig, wird in einer Liste nachgesehen ob es für dieses Kommando 
ein Message gibt und wenn ja wird die Message in die Input-Queue 
gestellt.

Ditto mit dem Menü. In der Menüdatenstruktur ist für jeden (einige) 
Menüpunkte angegeben, welche Message bei Auswahl zu wählen ist. Und 
wieder: wählt der Benutzer diesen Punkt aus, so wird die entsprechende 
Message in die Input-Queue gestellt. Die eigentliche Menüfunktionelität 
wird, µC entsprechend, zb in einem regelmässigen Timer-Interrupt gemacht 
(oder über die klassische Methode der Hauptschleife und Job-Flags oder 
...)

von Oha (Gast)


Lesenswert?

Eine Zustandsmaschine leistet das alles. Das Tool der Wahl ist ein 
State-Event-Action diagram. Das Menu ist in einem Zustand, ein Event ist 
ein Tastendruck, und nach einer Action resultiert ein neuer State.
Tastenabfrage im timer. Das Menu im main.

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
Noch kein Account? Hier anmelden.