...
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.