• STLink or UART bootloader
  • https://archive.is/TijL5
• CAN bootloader
  • https://www.st.com/resource/en/application_note/cd00264321-can-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf
  • https://pypi.org/project/canprog/
  • https://www.feaser.com/openblt/doku.php
  • https://www.eevblog.com/forum/microcontrollers/firmware-upgrade-over-can-bus-with-stm32/
  • https://community.st.com/t5/stm32-mcus/how-to-connect-to-the-stm32-can-bootloader-interface/ta-p/49283

I really like the CAN approach, as all the boards will already be connected and it would integrate neatly with the Pi binary management system, but there are problems with it:

• The "translator" board is not connected over CAN as it is on MQTT in order to talk to the Pis (Maybe there is an MQTT bootloader here? Maybe OpenBLT could be made to work over ethernet? This feels like it's going downhill)
• Each board will get different code loaded onto it, and I'm not sure how we distinguish what goes where

If we are using the binary manager for the STM boards too, then we should use a CAN bootloader. STLink and STM32CubeProgrammer would be simpler for the case where we're manually flashing each board, and will likely be the starting system, at least until we have STM32 binaries building outside of CubeIDE.

Might just be able to include https://github.com/STMicroelectronics/stm32f7xx_hal_driver/ or equivalent, wrap all the nasty C stuff in the IO libraries, and integrate that way? I am concerned it won't be that easy though