Page Comparison

...

This function will be split into two different commands, update ID and update name. These functions update the name or ID of a single controller board. The client sends out an ID to update and the new ID or name. The controller board overwrites the config (being careful to write one page, check it, and then write the other), and responds back with a status code. The client should not allow this to be run when more than one controller board is matched, or when the ID/name matches the ID/name of another controller board on the network; however, it can’t detect if the ID/name is used in a controller board not on the network, so be careful. The protobuf used will change based on which function is used (name vs ID).

The client → boards datagram should have the following format:

Update ID:

uint8 id = 6 // Use 6 here as the datagram ID to avoid conflicts 
uint16 data_size // Size of the protobuf (in n bytes)
uint8[n] data // The protobuf (located in the protos folder in the bootloader project: update_id.proto or)

Update name:

uint8 id = 7 // Use 7 here as the datagram ID to avoid conflicts 
uint16 data_size // Size of the protobuf (in n bytes)
uint8[n] data // The protobuf (located in the protos folder in the bootloader project: update_name.proto)

The response datagram will have the following format:

...

The client sends out IDs of the boards to flash to, metadata like project name, git version (+branch?) info, and application CRC and size, then the application code itself. The controller boards write the application code to flash (making sure not to keep it all in memory at once to avoid overflows) and compute their own CRC of the application code. If it matches, they overwrite the project name/git version info/application CRC/application size in the config and clear the project info (being careful to write one page, check it, and then write the other), then respond back with an “OK” status code message. If it doesn’t match, they mark their config as “no project” (again being careful) and respond back with an appropriate status code.

The first client → boards metadata datagram should have the following format:

uint8 id = 78 // Use 78 here as the datagram ID to avoid conflicts 
uint16 data_size // Size of the protobuf (in n bytes)
uint8[n] data // The protobuf (located in the protos folder in the bootloader project: flash_application_code.proto)

...

uint8 id = 0 // Use 0 here as the datagram ID to avoid conflicts 
uint16 data_size = 1 // This is the size of the status code in n bytes
uint8 data // The status code

Note: The application code is to be transmitted The client script will wait for this response from every controller board (or a timeout), then begin sending the application code in 2048-byte chunks in separate datagrams as raw data. A client → boards datagram containing 2048 bytes of application code looks like this:

uint8 id = 9 // Use 9 here as the datagram ID to avoid conflicts
uint16 data_size // Size of the data sent in bytes, up to 2048
uint8[n] data // The application code data chunk

If there are less than 2048 bytes of application code remaining, use a smaller data_size. After each such datagram is sent, the client script will wait for another response datagram from every controller board (or a timeout; this gives the controller board time to process the datagram and write it to flash):

uint8 id = 0 // Use 0 here as the datagram ID to avoid conflicts 
uint16 data_size = 1 // This is the size of the status code in n bytes
uint8 data // The status code

Once it has received a response datagram from every controller board, it sends the next chunk of application code data in another datagram until all the application code has been transferred.