Open salyzyn opened 2 years ago
This will cost a flashrom space. This may not be a problem for MCU's with large 16k first block, but it very sensitive for small MCU's. Also the DFU (not DFUse) don't support other interfaces
Flashrom space is always tradeoff, all firmware projects one would assume adding another transport would be a configuration option. Only affect those that want it. I only suggested this because the build-in bootblock for STM devices includes several interfaces/transport, one of which I desire (USART if the hint was not strong enough :-) ) .
When and if USART protocol becomes a priority for us (~1man/yr) and once we have the 'other end' of the USART link running, I would like to look into adding/testing it then, submitting it up for approval. I expect it to use the same protocol as the STM built-in bootloader, but would want (the optional) decryption running. Does that sound OK?
Consider allow adding another polling object in the loop so that multiple transports can be supported simultaneously. For instance, as per https://www.st.com/resource/en/application_note/cd00264342-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf, one could conceivably simultaneously support DFU on the USB bus, or serial flashing via a selected serial port. I can imagine this opening the door to USART, LIN, CAN, I2C, ETH & SDCard as transports to approach the functionality of the ST built-in bootloader feature set.