Are there, perchance, plans to provide a UAVCAN-compliant bootloader as part of the Viper MAV stack? Are there any Arduino compatibility issues one needs to be aware of? This is one of the first questions one would ask before building a product on top of this framework.
@aentinger is probably aware of Kocherga (currently only about 80% finished). I wonder if it were possible to somehow integrate this C++17 library with the Arduino environment?
Thank you very much for this suggestion, I would very much like to support a UAVCAN bootloader within the Viper MAV stack 
. Although I am peripherally aware of the kocherga project I must confess that I’ve not examined it in terms of suitability for integration into the Arduino platform.
In any case this bootloader would need to be implemented within an ArduinoCore (e.g. ArduinoCore-samd), as it is architectually impossible to build a bootloader as a Arduino library. Inclusion into the core is up the the Arduino development team so the situation could arise where the UAVCAN bootloader could only be available in a fork of an ArduinoCore.
This need not be a bad thing after all as I could imagine an ArduinoDroneCore or ArduinoUAVCANCore in the future which provides all the necessary functionality for rapid UAVCAN development. However, I must caution that this is a far-future-situation not achievable with current man-power 
Hi.
maybe this could also be achieved without modifying the ArduinoCore.
We just take kocherga bootloader and from the arduino side only the firmware binary. This wouldn’t work out of the box with just clicking the “Download” button in the Arduino IDE. But I think the uavcan users will always use their own configuration tool and also use this for downloading fimware.
For the firmware (developed with the Arduino IDE) it shouldn’t make a difference if it wasn’t installed by the Arduino bootloader but by the kocherga bootloader.
This wont work because the bootloader needs to reside at a fixed location in flash (preferably in the beginning). Therefore a flash section needs to be reserved in the linker script, which is part of the core.
I think Bernhard is suggesting a second-level bootloader that is executed after the native one but before starting the application. Technically it is a valid approach from the standpoint of the boot-up logic but I am not sure if it would integrate well with the Arduino ecosystem. Can you override the default load address when deploying the application from the Arduino IDE? I suspect this is not the case so then the user will have to always build application binaries together with the bootloader, which is awkward and again it may be hard to automate using the tools offered by the Arduino ecosystem.
I’ve got to acknowledge that a 2nd-level bootloader is feasible within the Arduino platform and in fact there are several 2nd-stage bootloaders (e.g. SFU, SDU, etc.) within ArduinoCore-samd. They work by storing the compiled bootloader in the first flash section following the bootloader.
My initial thinking that such a bootloader needs to be implemented within an Arduino core is therefore false (sorry @generationmake 
) because the reservation of the required flash space (section sketch_boot) at the start of the application already exists (at least within ArduinoCore-samd). Therefore a stand-alone Arduino library implementing the kocherga bootloader outside the core should be possible, as the sketch_boot symbol is available to any Arduino application compiled with ArduinoCore-samd.
Edit: Its worth noting that this approach is very flash consuming as large parts of the Arduino framework are compiled in, even if they are not needed. Furthermore the 2nd stage bootloader needs to be aligned with flash erase size and therefore consumes at least 8k flash (or 16k, 24k, 32k, etc.).