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