Das Report-Message-Protokoll

Das Report-Message-Protokoll


 

Im vorherigen Beispiel haben wir lediglich eine interne Kommunikation zwischen dem Button und der LED erzeugt. Dazu haben wir das "onChanged"-Event des Buttons mit dem "Led0Set"-EventHandler der LED verbunden. Wie die Kommunkation dabei ablief war für uns unwichtig. Im nächsten Schritt möchten wir das Beispiel so umbauen, dass der Button eine Meldung nach außen gibt und die LED ebenfalls von außen angesteuert wird. Genau dafür brauchen wir das Event "ReportMessage".

Doch um eine solche Nachricht gezielt auswerten zu können, müssen wir erstmal wissen, wie so eine Report-Message aussieht?

Der Aufbau einer Report-Message

 
  • A: Im 1. Byte ist der Befehl codiert.
  • B: Im 2. bis n. Byte befinden sich die Parameter.
  • C: Im letzten Byte ist eine einfache Checksumme enthalten, um die Übertragung zu prüfen.

Die Checksumme ermitteln Sie, in dem Sie alle Bytes über eine Exklusiv-Oder-Funktion verknüpfen.

Momentan gibt es die folgenden Befehle:

 

Befehl ist hier nicht ganz das richtige Wort, besser wäre vielleicht Nachricht. Wir haben schon gesehen, dass ein Button eine Report-Message senden kann. Diese wird durch ein Report-Event ausgelöst und deshalb beginnt die entsprechende Nachricht mit dem 1. Byte = 0x07.

Die Object ID ist spezifisch für die jeweilige Komponente, z. B. 0E für die LED und 1E für den Button. Gibt es mehrere Objekte einer Komponente, dann werden diese über den Objekt-Index identifiziert.

Sehr schön kann man sich das Ganze mit dem Tool "GTX" anschauen, das einen Simulator darstellt. Wenn wir dieses Programm für unseren momentane Konfiguration aufrufen, dann sieht es folgendermaßen aus:

 

Ich habe Objekte in der Übersicht, kann den aktiven Bildschirm wählen oder abfragen und ganz oben auch den Kontrast verändern.

Für unseren Button gibt es die Möglichkeit, über "Query" den Zustand zu erfragen oder den Button ferngesteuert anzuklicken. Wenn Sie das tun (bitte ins Bild klicken), erhalten Sie rechts zwei Ausgaben:

Die grüne Zeile ist der Befehl, den GTX ans Display gesendet hat, die rote Zeile kommt vom Display zurück. Gesendet wurde zunächst der Befehle:

01 1E 00 00 01 1E

Es handelt sich also um einen WRITE_OBJ-Befehl. Das könnte zunächst verwirren, aber die Objekte im GTX sind ja nicht die auf Ihrem Display, sondern deren Kommunikationspartner. GTX simuliert somit eigentlich den Host und nicht das Display. Ein Klick auf den Button formuliert den Befehl: "Schalte den Button"... und der Parameter am Schluss definiert: "einschalten". Klicken wir wieder auf den Button (bitte ins Bild klicken) so wird er wieder ausgeschaltet (auf dem realen Display natürlich). Der Rückgabewert (rote Zeile mit Wert 06) bedeutet übrigens, das alles glatt gelaufen ist, ansonsten würden wir eine 15 erhalten.

Jetzt fragen Sie sich vielleicht, wo denn jetzt hier die Report-Message ist, denn wir haben ja ausschließlich Befehle an das Display gesendet. Das stimmt, wir haben den Button bisher nur ferngsteuert, um eine Report-Message zu erhalten, müssen wir auf den realen Button drücken (bitte ins Bild klicken).

Jetzt erhalten wir eine rote Zeile, das heißt das Display hat sich gemeldet und sendet uns den Befehl, der mit 07 beginnt und somit ein REPORT_EVENT-Befehl ist.

Wir können also den Button ferngesteuert ein- und ausschalten, wir können seinen Zustand abfragen und wir können ihn auf dem Display drücken und erhalten eine Report-Message. Die LED können wir setzen (mit welchem Zustand können Sie über einen Klick auf die grüne runde Fläche bestimmen) oder abfragen.

Mit diesem Wissen realisieren wir jetzt eine konkrete Host-Display-Anwendung.