Changes between Version 26 and Version 27 of Software/Gateway

Timestamp:

11/26/10 11:13:22 (13 years ago)

Author:

art

Comment:

--

Software/Gateway

@@ -61 +61 @@
   <td style="background-color: #eeeeaa; width: 4em">dst</td>
   <td style="background-color: #eeffaa; width: 4em">len</td>
-  <td style="background-color: #eeeeee; width: 4em">x</td>
+  <td style="background-color: #eeeeee; width: 4em">lenx</td>
   <td style="background-color: #aaeeff; width: 4em" colspan="2">priority</td>
   <td style="background-color: #eeeeee; width: 4em">x</td>
@@ -117 +117 @@
 }}}
 
-Every message sent over the network and to/from the server must have this form. Here ''x'' indicates reserved/non-used bytes. ''src'' and ''dst'' are the IBus-Device identifiers (i.e. 0x18 for CD-Changer, 0x00 for GM, 0x68 for Radio, etc...) for source and destination respectively. ''len'' indicates the amount of bytes passed in the data field. Data field can be send in another TCP frame or together with the header. ''priority'' sets the priority of a message to be sent over IBus. 
+Every message sent over the network and to/from the server must have this form. Here ''x'' indicates reserved/non-used bytes (lenx is a second reserved byte for the length indication). ''src'' and ''dst'' are the IBus-Device identifiers (i.e. 0x18 for CD-Changer, 0x00 for GM, 0x68 for Radio, etc...) for source and destination respectively. ''len'' indicates the amount of bytes passed in the data field. Data field can be send in another TCP frame or together with the header. ''priority'' sets the priority of a message to be sent over IBus. 
 
 There are also exists special messages sent between server and the client. This special messages are required for establishing communication and checking if client is still alive for example. Every message in which header ''len'' is set to 0, is a special message. There are currently exist following special message types:
@@ -165 +165 @@
 
 In order to initiate firmware version check a client need send a message:
-  * '''GetFirmwareVersion''': ''src='f''', ''dst='g''' - Server will answer with the same message after some amount of time, where the current version is stored in the priority field of the header (high byte for major version and low byte for minor version)
+  * '''GetFirmwareVersion''': ''src='f' '', ''dst='g' '' - Server will answer with the same message after some amount of time, where the current version is stored in the priority field of the header (high byte for major version and low byte for minor version)
 
-
+Afterwards an update of the firmware can be initiated by the following protocol:
+  * send '''InitFirmwareUpdate''': ''src='f' '', ''dst='i' '' - which will cause server to initiate firmware update. The message must contain in the priority field the 32bit password which is specific to the flashed unit and the firmware. 
+  * receive '''InitFirmwareUpdate''' - wait for max 3sec. until server response with this message indicating that firmware can be now uploaded. 
+  * send '''UploadFirmware''': ''src='f' '', ''dst='u' '' - here the len:lenx is a 16bit number indicating the length in bytes of the data (i.e. firmware) following in the data part of the message. The priority field must contain the checksum (16 bit) delivered with the firmware data. And finally both last reserved bytes in the header must contain the firmware version we are uploading. The data field of this message must contain the full firmware data which will be directly uploaded to the unit.
+  * receive '''UploadFirmware''' - server responses with this message every time when next chunk of bytes has been uploaded to the device. Client application can use the response in order to indicate how much of the data has been already uploaded. The len:lenx field contains number of bytes already uploaded to the device.