Difference between revisions of "KONNEKTING Protocol Specification 0x01"
Konnekting (talk | contribs) |
Konnekting (talk | contribs) |
||
Line 561: | Line 561: | ||
|- | |- | ||
|0x01 | |0x01 | ||
− | | | + | |AddressTable checksum |
+ | |- | ||
+ | |0x02 | ||
+ | |AssociationTable checksum | ||
+ | |- | ||
+ | |0x03 | ||
+ | |CommObjectTable checksum | ||
+ | |- | ||
+ | |0x04 | ||
+ | |PaameterTable checksum | ||
|} | |} | ||
Revision as of 19:35, 3 November 2020
Workflow
The following describes the workflow for programming a KONNEKTING device. The diagrams show the required actions the programming device (f.i. KONNEKTING Suite) needs to do in order to program a KONNEKTING device.
Start Programming Mode
Before the programming can start, the KONNEKTING device needs to be in "programming mode" (short: ProgMode). The following diagram describes the two possible ways to achive ProgMode.
Do Programming
After ProgMode has been achived, it's time to do the actual device programming. For getting an answer for the "... changed?" decision-blocks, a comparison between the "DeviceMemory" section (see: https://gitlab.com/konnekting/KonnektingXmlSchema/blob/develop/src/main/xsd/KonnektingDeviceV0.xsd) of .kconfig.xml with the data the application wants to write. If there are any differences, data has to be written. Either complete, or only the blocks with changes (will speed up programming a lot, especially for small changes).
The parts for "Program CommObjects" and "Program Parameters" are optional an depend on what the user want to program. So you can skip or include them, as you like.
Working with files
This is about working with files, means transfering files to the device, including firmware upgrade
todo ...
Device Memory Layout
The device's memory is divided in multiple sections:
Hints:
- The AddressTable is sorted by the GroupAdress ascending by its integer value.
- The AssociationTable is sorted by the GroupAddress ID ascending by its integer value.
- Although a smaller checksum (CRC16 or CRC8) would be sufficient for those (small) tables in memory, it's a CRC32. This has the advantage that only one CRC algorithm is used (CRC32) for all things KONNEKTING required to check a checksum.
System Table
- Total table size in bytes: 32 bytes, first 16 bytes: fixed, read only; next 16 bytes: variable, readable/writeable
Access Mode | Table Byte Index | Description |
---|---|---|
R | 0 | version byte HI |
R | 1 | version byte LO |
R | 2 | #Device Flags |
R | 3 | #GroupAddress Table address HI |
R | 4 | GroupAddress Table address LO |
R | 5 | #Association Table address HI |
R | 6 | Association Table address LO |
R | 7 | #CommObject Table address HI |
R | 8 | CommObject Table address LO |
R | 9 | #Parameter Table address HI |
R | 10 | Parameter Table address LO |
R | 11..15 | 0xFF, unused |
R/W | 16..19 | CRC32 checksum of R/W segment |
R/W | 20 | IndividualAddress HI |
R/W | 21 | IndividualAddress LO |
R/W | 22..31 | 0xFF, unused |
Device Flags
b7 ist the left most bit, b0 is the right most bit.
bit | hex mask | Description |
---|---|---|
b7 | 0x80 | Factory flag:
|
b6 | 0x40 | IA flag:
|
b5 | 0x20 | CO flag:
|
b4 | 0x10 | Params flag:
|
b3 | 0x08 | data storage flag:
|
b2..b0 | n/a | unused |
GroupAddress Table
- Total table size in bytes: 4+1+(n*2) bytes, where n = GroupAddress limit, see #System_Type
Table Byte Index | Description |
---|---|
0..3 | checksum (CRC32) of following table bytes |
4 | number of filled entries in table |
5 | GroupAddress 0 HI |
6 | GroupAddress 0 LO |
7 | GroupAddress 1 HI |
8 | GroupAddress 1 LO |
9 | GroupAddress 2 HI |
10 | GroupAddress 2 LO |
... | ... |
Association Table
- Total table size in bytes: 4+1+(n*2) bytes, where n = GA-CommObj relation limit, see #System_Type
Table Byte Index | Description |
---|---|
0..3 | checksum (CRC32) of following table bytes |
4 | number of filled entries in GA<->CommObj relations table |
5 | GroupAddress ID Nr.1 |
6 | CommObj ID Nr.1 |
7 | GroupAddress ID Nr.2 |
8 | CommObj ID Nr.2 |
9 | GroupAddress ID Nr.3 |
10 | CommObj ID Nr.3 |
... | ... |
CommObject Table
- Total table size in bytes: 4+1+(n) bytes, where n = CommObjects limit, see #System_Type
Table Byte Index | Description |
---|---|
0..3 | checksum (CRC32) of following table bytes |
4 | number of existing CommObjects |
5 | config byte (see below) of CommObject ID 0 |
6 | config byte of CommObject ID 1 |
7 | config byte of CommObject ID 2 |
... | ... |
CommObject config byte
b7 ist the left most bit, b0 is the right most bit.
bit | hex mask | Description |
---|---|---|
b7 | 0x80 | unused, 0x00 |
b6 | 0x40 | unused, 0x00 |
b5 | 0x20 | C: the Communication flag |
b4 | 0x10 | R: the Read flag |
b3 | 0x08 | T: the Transmit flag |
b2 | 0x04 | W: the Write flag |
b1 | 0x02 | U: the Update flag |
b0 | 0x01 | I: the Initialization flag |
Parameter Table
- Total table size in bytes: depends on actual by device provided parameters + 4 bytes for checksum
Table Byte Index | Description |
---|---|
0..3 | checksum (CRC32) of following table bytes |
4 | ... |
5 | ... |
6 | ... |
7 | ... |
... | ... |
User Space
This is the space where user data can be stored. The KONNEKTING Device Library provides an API to query the start address for this user space in memory.
Property Pages
Property pages are blocks information with up to 12 bytes of length. Property pages are read-only and do not directly belong to the device's memory (f.i. EEPROM or Flash). The information is mostly stored in the device firmware.
0x00 Device Info
- Property Page Number: 0 dec / 0x00 hex
- Property Page Name: Device Information
Byte no# | Description |
---|---|
2 | Manufacturer-ID HI |
3 | Manufacturer-ID LO |
4 | Device-ID |
5 | RevisionID |
6 | System Type, see below |
7..13 | 0xFF, unused |
System Type
hex | Name | Description |
---|---|---|
0x00 | System 0 Simple |
Up to:
|
0x01 | System 1 Default |
Up to:
|
0x02 | System 2 Extended DRAFT |
Up to:
|
GAs = Unique GroupAddresses
GA-ComObj relations = Assignments of GAs to ComObjects
ComObjects = Number of ComObjects
Parameters = Number of Parameters
Message Types for Protocol-Version 0x01
These are the messages KONNEKTING uses to communicate between the programming device and the KONNEKTING device.
0x00 Acknowledge
- Message Name: Acknowledge
- Message-Type-ID: 0 dec / 0x00 hex
- Direction: Device -> Suite
- Expected Response: n/a
- Description: Sent by device as answer to most WRITE messages
- Requires Programming Mode: n/a
Byte no# | Description |
---|---|
2 | Acknowledge Type |
3 | Error Code |
4..13 | 0xFF, unused |
Acknowledge Type
hex | Description |
---|---|
0x00 | ACK |
0xFF | NACK |
Error Code
hex | Description |
---|---|
0x00 | ERR_CODE_OK |
0x01 | ERR_CODE_NOT_SUPPORTED |
0x02 | ERR_CODE_DATA_OPEN_WRITE_FAILED |
0x03 | ERR_CODE_DATA_OPEN_READ_FAILED |
0x04 | ERR_CODE_DATA_WRITE_FAILED |
0x05 | ERR_CODE_DATA_READ_FAILED |
0x06 | ERR_CODE_DATA_CRC_FAILED |
0x07 | ERR_CODE_TIMEOUT |
0x08 | ERR_CODE_ILLEGAL_STATE |
0x01 PropertyPageRead
- Message Name: PropertyPageRead
- Message-Type-ID: 1 dec / 0x01 hex
- Direction: Suite -> Device
- Expected Response: #0x02 PropertyPageResponse
- Description: Read one page of property data
- Requires Programming Mode: no
Byte no# | Description |
---|---|
2 | addressflag: 0x00=only reply when progmode is set; 0xFF=only reply if following IA does match |
3 | IndividualAddress HI; 0xFF/unused if b[2]=0x00 |
4 | IndividualAddress LO; 0xFF/unused if b[2]=0x00 |
5 | property page num, 0x00..0xFF, see #Property Pages for more details |
6..13 | 0xFF, unused |
0x02 PropertyPageResponse
- Message Name: PropertyPageResponse
- Message-Type-ID: 2 dec / 0x02 hex
- Direction: Device -> Suite
- Expected Response: n/a
- Description: One page of property data
- Requires Programming Mode: no
Byte no# | Description |
---|---|
2..13 | 12 bytes of property page data, see #Property Pages for more details |
0x03 SetChecksum
- Message Name: SetChecksum
- Message-Type-ID: 3 dec / 0x03 hex
- Direction: Suite -> Device
- Expected Response: n/a
- Description: store a CRC value
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | CRC identifier |
3..6 | CRC32, 4 byte value |
7..16 | 0xFF, unused |
CRC identifier
hex | Description |
---|---|
0x00 | SystemTable checksum |
0x01 | AddressTable checksum |
0x02 | AssociationTable checksum |
0x03 | CommObjectTable checksum |
0x04 | PaameterTable checksum |
0x08 Unload
- Message Name: Unload
- Message-Type-ID: 8 dec / 0x08 hex
- Direction: Suite -> Device
- Expected Response: #0x00 Acknowledge
- Description: Unload device. After successfull unload, device will reboot.
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Factory Reset, 0x00 = false, 0xFF=true if true, all other bits are irrelevant |
3 | Unload Individual Address, 0x00 = false, 0xFF=true |
4 | Unload ComObjects, 0x00 = false, 0xFF=true |
5 | Unload Parameters, 0x00 = false, 0xFF=true |
6 | Unload data storage (see: #0x28 DataWriteprepare etc), 0x00 = false, 0xFF=true |
7..13 | 0xFF, unused |
0x09 Restart
- Message Name: Restart
- Message-Type-ID: 9 dec / 0x09 hex
- Direction: Suite -> Device
- Expected Response: #0x00 Acknowledge
- Description: Restart device (device reboot, no memory reset)
- Requires Programming Mode: no
Byte no# | Description |
---|---|
2 | IndividualAddress HI |
3 | IndividualAddress LO |
4..13 | 0xFF, unused |
0x0A ProgrammingModeWrite
- Message Name: ProgrammingModeWrite
- Message-Type-ID: 10 dec / 0x0A hex
- Direction: Suite -> Device
- Expected Response: #0x00 Acknowledge
- Description: Sets/Unsets Programming-Mode for device with given individual address. Device will respond with a "Acknowledge" message.
- Requires Programming Mode: no
Byte no# | Description |
---|---|
2 | IndividualAddress HI |
3 | IndividualAddress LO |
4 | Mode: 0x00 = OFF |
5..13 | 0xFF, unused |
0x0B ProgrammingModeRead
- Message Name: ProgrammingModeRead
- Message-Type-ID: 11 dec / 0x10 hex
- Direction: Suite -> Device
- Expected Response: #0x0C ProgrammingModeResponse
- Description: Reads current programming mode of all listening devices. If more than one device is in programming-mode, you will get more then one #0x0C ProgrammingModeResponse messages.
- Requires Programming Mode: no
Byte no# | Description |
---|---|
2..13 | 0xFF, unused |
0x0C ProgrammingModeResponse
- Message Name: ProgrammingModeResponse
- Message-Type-ID: 12 dec / 0x11 hex
- Direction: Device -> Suite
- Expected Response: n/a
- Description: Response to ProgrammingModeRead message.
- Requires Programming Mode: n/a
Byte no# | Description |
---|---|
2 | IndividualAddress HI |
3 | IndividualAddress LO |
4..13 | 0xFF, unused |
0x1E MemoryWrite
- Message Name: MemoryWrite
- Message-Type-ID: 30 dec / 0x1E hex
- Direction: Suite -> Device
- Expected Response: #0x00 Acknowledge
- Description: Write data to device memory
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Count: Number of bytes to write to memory, starting at "Address" |
3 | Address uint16[0] HI |
4 | Address uint16[1] LO |
5..13 | 1..9 bytes of Data, depends on "Count". Remaining bytes: 0xFF |
0x1F MemoryRead
- Message Name: MemoryRead
- Message-Type-ID: 31 dec / 0x1F hex
- Direction: Suite -> Device
- Expected Response: #0x20 MemoryResponse
- Description: Reads data from device memory
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Count: Number of bytes to read from address. Range 1..9 |
3 | Address HI |
4 | Address LO |
5..13 | 0xFF, unused |
Memory Tables
With help of #0x1F MemoryRead and #0x1E MemoryWrite one can access the device's memory (EEPROM, flash, ...). The memory stores different tables for different usage. As both messages access memory by memory address, one has to know at which address which table starts. To get the start addresses of all tables, see #System Table.
0x20 MemoryResponse
- Message Name: MemoryResponse
- Message-Type-ID: 32 dec / 0x20 hex
- Direction: Device -> Suite
- Expected Response: n/a
- Description: Response to MemoryRead
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Count: Number of bytes that have been read from address |
3 | Address HI |
4 | Address LO |
5..13 | 1..9 bytes of Data, depends on "Count". Remaining bytes: 0xFF |
0x28 DataWritePrepare
- Message Name: DataWritePrepare
- Message-Type-ID: 40 dec / 0x28 hex
- Direction: Suite -> Device
- Expected Response: #0x00 Acknowledge
- Description: prepare writing data
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Data Type, see below |
3 | Data ID unique identifier for the data |
4 | size of data uint32[0] |
5 | size of data uint32[1] |
6 | size of data uint32[2] |
7 | size of data uint32[3] |
8..13 | unused, 0xFF |
Data Type
hex | Name | Data ID range | Description |
---|---|---|---|
0x00 | UPDATE | always 0x00 | Firmware update for KONNEKTING device |
0x01 | DATA | 0x00..0xFF | f.i. additional configuration, images, sounds, ... |
0x29 DataWrite
- Message Name: DataWrite
- Message-Type-ID: 41 dec / 0x29 hex
- Direction: Suite -> Device
- Expected Response: #0x00 Acknowledge
- Description: Writing data
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Count[1]: 1..11 bytes |
3..13 | 1..11 bytes of Data, depends on "Count". Remaining bytes: 0xFF |
Notes:
- ↑ required to determin the end of data in last DataWrite message
0x2A DataWriteFinish
- Message Name: DataWriteFinish
- Message-Type-ID: 42 dec / 0x2A hex
- Description: finish writing data
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | CRC32[0] [1] |
3 | CRC32[1] |
4 | CRC32[2] |
5 | CRC32[3] |
6..13 | unused, 0xFF |
Notes:
0x2B DataRead
- Message Name: DataRead
- Message-Type-ID: 43 dec / 0x2B hex
- Direction: Suite -> Device
- Expected Response: #0x2C DataReadResponse, providing the size, followed by n times #0x2D DataReadData until end of data and finally again #0x2C DataReadResponse, providing the CRC32
- Description: trigger reading data
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Data Type range: 0x01..01FF (0x00 can't be read, as this is firmware) |
3 | Data ID unique identifier for the data to read |
4..13 | unused, 0xFF |
0x2C DataReadResponse
- Message Name: DataReadResponse
- Message-Type-ID: 44 dec / 0x2C hex
- Direction: Device -> Suite
- Expected Response: n/a
- Description: meta data about the requested data. The actual data will follow in separate messages (#0x2D DataReadData)
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Data Type |
3 | Data ID unique identifier for the data |
4 | size of data uint32[0] |
5 | size of data uint32[1] |
6 | size of data uint32[2] |
7 | size of data uint32[3] |
8 | CRC32[0] [1] |
9 | CRC32[1] |
10 | CRC32[2] |
11 | CRC32[3] |
12..13 | unused, 0xFF |
0x2D DataReadData
- Message Name: DataReadData
- Message-Type-ID: 45 dec / 0x2D hex
- Direction: Device -> Suite
- Expected Response: #0x00 Acknowledge
- Description: packet of requested data from device. Device will send several messages of this type until whole data is transferred
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Count[2]: 1..11 bytes |
3..13 | 1..11 bytes of Data, depends on "Count". Remaining bytes: 0xFF |
0x2E DataRemove
- Message Name: DataRemove
- Message-Type-ID: 46 dec / 0x2E hex
- Direction: Suite -> Device
- Expected Response: #0x00 Acknowledge
- Description: remove previously stored data
- Requires Programming Mode: yes
Byte no# | Description |
---|---|
2 | Data Type range: 0x01..0xFF[3] |
3 | Data ID unique identifier for the data |
4..13 | unused, 0xFF |
Notes:
- ↑ https://github.com/bakercp/CRC32
- ↑ required to determin the end of data in message
- ↑ 0x00 is reserved for UPDATE