Die Group Object Table ist ein Teil der Informationsübertragung zwischen ETS und KNX Gerät.
Sie dient dazu, die Kommunikationsobjekte zu beschreiben.
In dieser Tabelle wird die Verknüpfung zwischen Kommunikationsobjekt und dem Speicherplatz des eigentlichen Wertes im Speicher des KNX Gerätes hergestellt, sowie die Beschreibung der Flags (Write, Communication, Read,...) und der aktuelle Status des Kommunikationsobjektes wird abgelegt.
Die Group Object Table wird als ein Teil der gesamten Übertragungsprozedur von der ETS mittels „DMA“ an das KNX Gerät übertragen. An welche Speicherstelle sie übertragen wird, ist in der knxprod beschrieben. Näheres dazu im Beispiel.
Beschrieben ist die GroupObject Table im Dokument "03_05_01 Resources" des KNX Standards im Kapitel 4.12
Der Anfang der GroupObject Table ist immer die aktuelle Größe der Tabelle. Diese Information benötigt ein Byte.
Anschließend ist ein-RAM-Flags Pointer vorgesehen, für eine BCU1 1 Byte groß, für eine BCU2 und BIM112 2 Byte groß.
Anschließend werden die einzelnen Kommunikationsobjekte abgelegt. Wichtig ist hierbei zu beachten, dass immer das Kommunikationsobjekt mit der höchsten Nummer zählt. Wenn es also das Kommunikationobjekt Nummer 0, 1, 2 und 10 gibt, werden für 10 Kommunikationsobjekte der Platz reserviert.
Bei einer BCU1 nimmt der Group Object Descriptor von jedem Kommunikationsobjekt 3 Bytes in Anspruch:
1 Byte Data Pointer (Zeiger auf die Daten im RAM)
1 Byte Config
1 Byte Type
Bei derr BCU2 oder BIM112 nimmt der Group Object Descriptor von jedem Kommunikationobjekt 4 Bytes in Anspruch:
2 Byte Data Pointer
1 Byte Config
1 Byte Type
|
|
|
Group Objects Table |
|
1 Byte |
|
Current Size |
|
1 Byte (BCU1) ; 2 Byte (BCU2, BIM112) |
|
RAM-Flags-Table Pointer |
|
3 Byte (BCU1) ; 4 Byte (BCU2, BIM112) |
KO Nr.0 |
Group Object Descriptor |
|
3 Byte (BCU1) ; 4 Byte (BCU2, BIM112) |
KO Nr. 1 |
Group Object Descriptor |
|
3 Byte (BCU1) ; 4 Byte (BCU2, BIM112) |
KO Nr. 2 |
Group Object Descriptor |
|
… |
… |
… |
Abbildung 1: Aufbau der GroupObject Table
Der RAM-Flags-Table Pointer
Der RAM-Flags-Table Pointer zeigt auf eine Tabelle, in der der aktuelle Status von jedem Kommunikationsobjekt gespeichert wird. Diese Tabelle liegt wie die Daten der Kommunikationsobjekte auch im User-RAM und ist in den kommerziellen knxprod Dateien teilweise vor oder auch nach den Group Object Descriptoren im RAM zu finden.
Die Tabelle besteht aus 1 Byte großen Einträgen, jeweils einer davon zuständig für ein Kommunikationsobjekt.
Abbildung 1: Aufbau eines RAM-Flags-Table Eintrags (Quelle: BCU1 helpfile)
Der Transmission Status ist folgendermaßen codiert:
Transmission Status
0x00: Idle/OK
0x01: Idle/Error
0x02: Transmitting
0x03: Transmission request
Der Group Object Descriptor
Im Group Object Descriptor sind der Data Pointer, das Config Byte und das Type Byte enthalten.
Der Data Pointer ist je nach Mask Version (BCU1, BIM112....) 1 oder 2 Byte groß.
Abbildung 2: Der Group Object Descriptor Eintrag
Der Data Pointer
Der Data Pointer zeigt auf den User RAM Speicherbereich der sblib. An der Stelle des gezeigten Speichers liegt die eigentliche Variable bzw. der Wert des Kommunikationsobjektes.
Da Kommunikationsobjekte verschiedene Größen haben können, ist dieser Speicherbereich komplett frei verfügbar und nicht fest eingeteilt.
Das Config Byte
Das Config Byte beinhaltet die Flags, die in der ETS gesetzt wurden:
Abbildung 3: Tabelle der Bits im Config Byte
Abbildung 4: Auflösung der Transmission Priority
Das Type Byte
Das Type Byte gibt an, welche Größe das Kommunikationsobjekt hat.
Abbildung 5: Die Bedeutung des Type Bytes
Ein Beispiel
Diese Informationen werden durch ein <Data> Abschnitt in der knxprod bzw. der XML des Applikationsprogramms bereitgestellt.
Die <Data> Sektion ist dem <AbsoluteSegment> oder <RelativeSegement> angehängt, welches in der <ComObjectTable> als <CodeSegemnt> genannt wurde.
Beispielsweise beginnt die < ComObjectTable> folgendermaßen:
<ComObjectTable CodeSegment="M-004C_A-0032-20-6CD5_AS-4400" Offset="0">
Damit ist dann in der <Code> Sektion der Eintrag mit der ID „M-004C_A-0032-20-6CD5_AS-4400“ zu suchen.In der CodeSegment Sektion mit dieser ID ist dann eine <Data> Sektion angehängt.
In diesem Beispiel sieht das folgendermaßen aus:
<AbsoluteSegment Id="M-004C_A-0032-20-6CD5_AS-4400" Size="1286" Address="17408">
<Data>XAcAB1zfAwec3wMH3N8ACBzfAAhc3wAHYN8DB6DfAwfg3w…</Data>
</AbsoluteSegment>
Die Adresse, an die diese Daten geschrieben werden ist in dezimal angegeben und in diesem Fall die Adresse 17408 = 0x4400, welche in das von der sblib bereitgestellte User EEPROM (0x3F00 bis 0x4B00) passt.
Wie man erkennen kann, kann an leider sind die Informationen aus der <Data> Sektion nicht einfach so lesen. Es sind alle Groß- und Kleinbuchstaben, Zahlen und auch Sonderzeichen in der Datenbeschreibung enthalten. Das Geheimnis liegt in der Codierung der Daten: Es ist eine Base64 Codierung. In dem Beispiel von oben repräsentieren die Daten folgende Werte:
0x5c 0x07 0x00 0x07 0x5C 0xDF 0x03 0x07 0x9c 0xDF 0x03 0x07 0xDC 0xDF 0x00 0x08 0x1C 0xDF 0x00 0x08 0x5C 0xDF 0x00 0x07 0x60 0xDF 0x03 0x07 0xA0 0xDF 0x03 0x07 0xE0 0xDF
Hier die gleichen Daten noch einmal in dem Schema der GroupObject Table.
|
|
|
Group Objects Table |
|
1 Byte Size |
|
0x5C = 92(dez) |
|
2 Byte RAM-Flags-Table Pointer |
|
0x0700 = 1792(dez) |
|
2 Byte Data Pointer |
KO Nr. 0 |
0x075C = 1884(dez) |
|
1 Byte Config |
KO Nr. 0 |
0xDF = 1101 1111(bin) |
|
1 Byte Type |
KO Nr. 0 |
0x03 = 3(dez) |
|
2 Byte Data Pointer |
KO Nr. 1 |
0x079C = 1948(dez) |
|
1 Byte Config |
KO Nr. 1 |
0xDF = 1101 1111(bin) |
|
1 Byte Type |
KO Nr. 1 |
0x03 = 3(dez) |
|
2 Byte Data Pointer |
KO Nr. 2 |
0x07DC = 2012(dez) |
|
1 Byte Config |
KO Nr. 2 |
0xDF = 1101 1111(bin) |
|
1 Byte Type |
KO Nr. 2 |
0x00 = 0(dez) |
|
… |
… |
… |
Abbildung 6: Die ersten 3 Kommunikationsobjekte aus den Beispieldaten
Dieses kann leicht durch einen im Internet zu findenden Online Decoder umgerechnet werden.
Das dieses Beispiel aus einer knxprod für ein BIM112 Gerät stammt, müssen immer 2 Byte für die Data Pointer und den RAM-Flags-Pointer berechnet werden.
Daher ist die Größe der Tabelle im ersten Byte mit 0x5c = 92(dez) angegeben (damit ist die Anzahl der Kommunikationsobjekte gemeint).
Der RAM-Flags-Table Pointer ist in diesem Fall 2 Byte groß und damit im zweiten und dritten Byte enthalten.
Hier ist die Endianess zu beachten! In der sblib wird standardmäßig von BIG ENDIAN ausgegangen. Das dürfte in diesem Fall auch stimmen, da die Adresse des RAM-Flags-Table Pointers mit 0x075C = 1884(dez) in den User RAM Bereich (0x5FC bis 0x900) der sblib zeigt.
Anschließend ist der Data Pointer des Kommunikationsobjektes 0 im vierten und fünften Byte zu finden. Dieser Pointer zeigt auf die gleiche Adresse wie der RAM-Flags-Table Pointer, nämlich 0x075C = 1884(dez).
Im nächsten Byte ist die Config des Kommunikationsobjektes 0 zu finden. Mit dem Wert 0xDF = 11011111(bin) lässt sich folgendes ablesen:
Bit 7: Wert 1: soll immer 1 sein
Bit 6: Wert 1: Transmit Enable
Bit 5: Wert 0: Segment Selector Type
Bit 4: Wert 1: Write Enable
Bit 3: Wert 1: Read Enable
Bit 2: Wert 1: Communication Enable
Bit 1: Wert 1: Transmission Priority
Bit 0: Wert 1: Transmission Priority : 11 = low priority
Im siebten Byte ist dann der Type des Kommunikationsobjektes 0 zu finden. Hier ist der Wert 0x03 = 3(dez), was nach der Tabelle für den Type eine Größe des Kommunikationsobjektes von 4 bits ist.
Eine eigene Produktdatenbank erzeugen
Zu erzeugen einer eigenen Produktdatenbank reicht es aus, die Data Pointer mit den korrekten Werten zu füllen.
Tests mit der ETS 5.7.2 haben ergeben, dass die Config und Type Bytes direkt erzeugt werden und nicht aus den Daten der knxprod genommen werden.