Kompatibilität und Migration
Die GUI-Bibliothek ist weitgehend kompatibel zum GUI-Interpreter unserer LCM2-Module. Daher lassen sich Anwendungen, die Sie für ein LCM2-Modul realisiert haben leicht zu einer GUI-Bibliotheks-Anwendung auf einer kundenspezifische Zielhardware portieren.
Die LCM2-Module werden von der Anwendungshardware durch das Senden von Kommandos gesteuert. Deshalb unterscheiden sie sich zunächst deutlich von Anwendungen, die mit der GUI-Bibliothek erstellt wurden. Für die Anwendungsentwicklung jedoch kann dieser Unterschied "versteckt" werden, so daß die Quelltexte sich sehr stark ähneln.
Eine Übersicht zeigt die folgende Tabelle:
| Anwendung für GUI-Bibliothek |
Anwendung für LCM2-Modul |
| Display-Befehle werden direkt für die kundenspezifische Hardware compiliert und dort ausgeführt |
Displaybefehle werden als Datenpakete von der Kundenhardware an das LCM2-Modul gesendet. Dort werden sie vom GUI-Interpreter ausgeführt. Die Kommunikation folgt einem "Master-Slave"-Modell (die Kundenhardware kontrolliert die gesamte Applikation und ist daher der "Master", das LCM2 führt lediglich Befehle aus und ist daher der "Slave").
|
| Um einen Displaybefehl auszuführen, verwendet man in der Anwendung direkt einen der zahlreichen Befehle der GUI-Bibliothek, z.B. die Funktion "disp_text" (Anzeige von Text). |
Um einen Displaybefehl auszuführen, muß man in der Anwendung das entsprechende Datenpaket erzeugen und an das LCM-Modul senden.
Für die Erzeugung dieser Datenpakete steht unseren Kunden eine Bibliothek zur Verfügung (die GUI-Master-LIB, geschrieben in ANSI-C, ist Bestandteil der Starterkits). Diese stellt Funktionen analog zu denen in der GUI-Bibliothek zur Verfügung, z.B. auch eine Funktion "disp_text" (Anzeige von Text).
|
Beispiel für den Aufruf einer GUI-Bibliotheks-Funktion:
disp_text("Hallo Welt"); |
Beispiel für den Aufruf einer Funktion zur Ansteuerung des LCM2-Bedienmodules:
disp_text("Hallo Welt");
|
| Interner Ablauf: Die Funktion disp_text veranlasst das Zusammensetzen (Rendering) der grafischen Pixel zu der Textausgabe und steuert entsprechend den verwendeten LCD-Controller auf der Kundenhardware an. |
Interner Ablauf: Die Funktion disp_text stellt ein entsprechendes Datenpaket zusammen und sendet es an das LCM2-Modul.
|
Resultat: "Hallo Welt" wird auf dem Display angezeigt.
Der Funktionsaufruf ist derselbe wie beim Ansteuern von LCM2-Modulen. |
Resultat: "Hallo Welt" wird auf dem Display angezeigt.
Der Funktionsaufruf ist derselbe wie beim der Verwendung der GUI-Bibliothek auf einer kundenspezifischen Hardware.
|
Die wichtige Frage nach dem Grad der Kompatibilität kann folgendermaßen beantwortet werden:
Es gibt einige Unterschiede, so daß ein einfaches "Compilieren für die andere Art der Anwendung" nicht direkt möglich ist.
Die Änderungen, die für eine Migration vorgenommen werden müssen sind jedoch nur gering und betreffen einzelne lokale Stellen im Code, nicht aber die Logik der Verwendung der Display-Funktionen. Diese Änderungen sind daher ohne großen Zeitaufwand (üblicherweise durch "Suchen und Ersetzen") durchführbar.
Die folgende Tabelle zeigt, wo Unterschiede bestehen, und wie man die Migration vornimmt:
| Fall |
Unterschied GUI-Bibliothek/
LCM2-Ansteuerung |
Arbeit zur Migration |
| Initialisierung |
Die GUI-Bibliotheks-Anwendung muß die kundenspezifische Hardware initialisieren. Dies unterscheidet sich von der Initialisierung der Kommunikation zum LCM2-Modul. |
Die jeweiligen Initialisierungssequenzen sind auszutauschen. |
| Spezielle Befehle zur Steuerung der Hardware, z. B. zur Einstellung der Helligkeit des Displays. |
Für die GUI-Bibliothek sind entsprechende Funktionsrümpfe vorhanden, und müssen passend zur verwendeten Hardware gefüllt werden.
Für die LCM2-Module sind die Funktionen komplett implementiert und können direkt aufgerufen werden. |
Für eine kundenspezifische Hardware mit GUI-Bibliothek sind Funktionen für die Steuerung dieser Hardware zu implementieren. |
| Funktionen mit Text zur Ausgabe auf dem Display oder mit Zahlen als Parameter (z.B. disp_text). Dies sind die meisten Funktionen. |
Funktionen sehen genauso aus und haben auch denselben Funktionsprototyp (Bsp.: err_code disp_text(char* dertext); |
Keine (der häufigste Fall). |
Statische Objekte:
- Grafiken
- Touch-Keyboards
- zusätzliche Zeichensätze
- Füllmuster
- Texte für spezielle Zwecke, die nicht mit "disp_text" direkt angezeigt werden, z.B. Button-Beschriftungen
|
In Anwendungen mit der GUI-Bibliothek werden die Objektdaten in den Quelltext eingefügt. Die Objekte sind dann durch den Zeiger auf die Daten charakterisiert.
Für eine Anwendung mit dem LCM2 werden diese Objekte direkt in das LCM2 "hochgeladen". Die Objekte sind dann gekennzeichnet durch eine "Object-ID". |
Statische Objekte, auf die von der LCM2-Anwendung zugegriffen wird, müssen in das LCM2 übertragen werden (ins Flash oder ins RAM). Für eine typische Anwendung betrifft dies normalerweise nur eine wenige Objekte.
Oft kann das "Hochladen" mit einfachen Funktionen einmal am Anfang der Anwendung geschehen, so daß deswegen an anderer Stelle keine Änderungen notwendig sind. |
Funktionen, die als Parameter ein "Objekt" haben.
Beispiel: Ein Bitmap-Bild soll mit der Funktion disp_bmp angezeigt werden. Aufruf in beiden Fällen:
disp_bmp(testbild); |
In der GUI-Bibliothek wird direkt über Zeiger auf die Objektdaten, z.B. die Bilddaten zugegriffen.
Für eine Anwendung mit dem LCM2 wird die Object-ID des Objekts übergeben und an das LCM2 übermittelt.
Der Aufruf der Funktionen sieht gleich aus, die Parameter, die die Objekte kennzeichnen sind aber für die GUI-Bibliothek vom Typ des Objektes selbst, für die LCM2-Ansteuerung vom generischen Typ "TObjectID" |
Die Datentypen, die das Objekt repräsentieren, unterscheiden sich, und müssen bei der Deklaration der Variable ausgetauscht werden (das passiert nur an einer Stelle, typischerweise gut zu finden am Anfang der Funktion).
Der Aufruf der Funktionen, die das Objekt benutzen, ändert sich nicht. |
Fazit:
Die Arbeiten für die Migration sind also recht gering und bestehen zu einem guten Teil aus dem Erstellen von Funktionen, die für eine kundenspezifische Hardware sowieso erstellt werden müssen (Initialisierung, Ansteuerung von Spannungsquellen für Displaybeleuchtung oder Kontrast).
Die verbleibenden Änderungen bestehen aus Ersetzungen von Deklarationen, die leicht am Anfang der Funktionen vorgenommen werden können ("suchen + ersetzen").
 
|