Konzept Menu und Schnittstelle

Geht das mit Strukturen?

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

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.

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