...
We’d have to choose an appropriate message ID to reserve. 0 or 1 might be appropriate because ACKs are sent for critical messages so they are themselves critical; in particular ACKs are used for the BPS heartbeat system and power sequence messages. Since critical messages aren’t sent too often it probably doesn’t matter the exact value as long as it’s lower than all the messages sent frequently/continuously.
Switch to the extended CAN frame format
CAN 2.0 B has an additional frame format: “extended”. The only difference is that the arbitration ID is now 29 bits long instead of 11, so this would solve all our ID allocation crunch issues. We would just have to make sure that all our devices and tooling support extended frames / update those that don’t.
As a bonus, regular (11-bit ID) and extended frames can coexist on the same bus, and all regular frames have priority over all extended frames. So, we could use extended frames for normal operation and use regular frames for e.g. the bootloader (which is what is done by github.com/cvra/can-bootloader).
Continuous Deployment (CD) for firmware and other onboard code
Prerequisites: get the bootloader working.
The current practice for updating firmware and other onboard code (telemetry scripts, driver display frontend code, strategy models, etc) is/will be to physically get at the boards/rPis with a cable and update them individually. This is fine, but it would be cool to automate it.
Picture this: on every commit to master, a GitHub Actions CD workflow pushes a notification to the telemetry rPi in the car, which pops up a Tesla-style “Firmware update available!” notification on infotainment. If the user selects yes, it clones/pulls the firmware_xiv repo and uses the bootloader to automatically update every board which needs updating.
This could even be extended to telemetry and strategy Python scripts (and driver display Dart) too. Pretty cool! Might get us some points for usability (maybe)!
FreeRTOS Plus
FreeRTOS has a bunch of extension libraries collectively called FreeRTOS Plus which might be interesting to explore in the future.
FreeRTOS+TCP/IP: a 20KB network stack for FreeRTOS that would let us connect to the internet or another network.
FreeRTOS+IO: an abstraction over UART/I2C/SPI serial peripherals with an interface like POSIX files.
FreeRTOS+CLI: a command interpreter, looks like we could hook it up to UART and maybe get a CLI working over minicom.
A neat backoff algorithm for spacing out network requests.