Hmm, meine letzten Displayanwendungen für Controller liefen immer nach dem gleichen Schema:
Eingänge (Peripheriewerte, Tastaturereignisse, Schnittstellentelegramme, Maskenwechsel und zeitgesteuerte Trigger für z.B. Animationen oder das Cursorblinken) festlegen und damit eine gemeinsame Schnittstelle für alle Bildschirmmasken definieren. Beispiel: Die Routine zur Abfrage der Tastatur ruft bei erkanntem Tastendruck die Funktion ActiveMask.KeyIn(int keyNum) auf.
Ausgänge (Displayinhalt, Peripherie-/EEPROM-Werte, LEDs, Buzzer, ...) in einzelnen Modulen abstrahieren und entsprechende Funktionen zur Verfügung stellen. Z.B. Display.WriteText(string s, int x, int y, bool reverse)
Zwischen Ein- und Ausgänge quetscht man nun die Bildschirmmasken. Objektorientiert würde man wohl zuerst eine Basisklasse mit abstrakten oder virtuellen Methoden für die Eingänge programmieren und anschließend die eigentlichen Bildschirmmasken jeweils davon ableiten. Mit Standard-C geht es über das Anmelden von Callbacks, also Funktionszeigern.
Letztlich aber leitet man so bei beiden Methoden über das Setzen der "ActiveMask" alle Eingänge auf die aktive Bildschirmmaske. Die Maske kann dann im Code selbst entscheiden, ob sie z.B. ein PeripherieValueChanged(pvData* data) überhaupt in der Ansicht hat und entsprechend reagieren muss.
Vom Programmablauf gesehen kannst Du Dir das dann so vorstellen:
Die Abfrage Deiner Eingänge per Loop oder Interrupt bilden das zeitliche Rückgrat Deiner Applikation (den Zyklus). Das Ergebnis der Abfrage eines Eingangs wird per entsprechender Funktion an die aktive Bildschirmmaske weitergeleitet, die ihrerseits Ausgänge manipuliert. Die Bildschirmmaske selber hat aber keine Loop und wartet auch nicht. Sie bremst also die Eingangsabfragen nicht aus. Einen Eingabewert aus mehreren Tastendrücken z.B. muss sie über eine Statemachine (max. Anzahl Eingabestellen + Eingabeüberprüfung) aus den einzelnen Aufrufen von KeyIn(int keyNum) zusammensetzen. Das ist zwar kompliziert, hat aber den Vorteil, dass man auf dem Display einen Sollwert editieren kann, während zusätzlich dargestellte Istwerte sich laufend aktualisieren.
Das gleiche gilt für die Ausgänge: Das Schalten einer LED verursacht sicherlich keine zeitlichen Verzögerungen. Beim Aktualisieren des gesamten Bildschirmes kann es Optimierungsbedarf geben (nur aktualisierte Bildschirminhalte ausgeben, ggf. das "Übersetzen" von Text in Pixel in die Loop der Eingänge übernehmen). Also auch diese Aufrufe kurz halten und nichts einbauen, was die Eingangsabfragen bremsen könnte.
Zitieren
Lesezeichen