...
That is, the CAN message consists of 8 uint8s, the first of which is a babydriver-specific ID. The other 7 uint8s are generic data fields, the meaning of which is determined by the ID. Babydriver message IDs will be defined in an enum in C and a series of constants in Python.
| Info |
|---|
Any multi-byte fields in a Babydriver CAN message (like using two uint8s to represent a uint16) should be in little-endian order to match the native STM32F0xx byte order. That is, the least significant byte should be specified first and the most significant byte last. |
We’ll have a generic status message sent by the firmware project at the end of any operation, allocating the uint8s as follows:
...
| Code Block |
|---|
uint8 id = X // some constant defined in C/Python uint8 port // port of gpio pin to set uint8 pin // pin number of gpio pin to set uint8 state. // 1 or 0 to set to high or low respectively |
...
| Code Block |
|---|
Metadata message 1: uint8 id = X // some constant uint8 spi_port // 0 or 1 for SPI_PORT_1 or SPI_PORT_2 uint8 tx_len_highlow // highlow byte of tx_len (a uint16) uint8 tx_len_low high // lowhigh byte of tx_len uint8 rx_len_highlow // highlow byte of rx_len (another uint16) uint8 rx_len_lowhigh // lowhigh byte of rx_len uint8 cs_port // port of chip select gpio pin uint8 cs_pin // pin of chip select gpio pin |
...
Note that since we’re representing everything as uint8s, we have to break up multiple-byte fields into their individual bytes and reconstruct them. This sucks, but it is what it is. Again, we use little-endian order to match the native STM32F0xx byte order.
The Python project will then send enough generic “babydriver data” messages (another type of message with just 7 uint8s) to cover tx_len. The firmware project will send back enough generic data messages to cover the rx_len bytes received, then the status message.
...