Wireless Bootloader

[zingbat]

To circle back on this: I've built an RFM69 library that is dependency free and doesn't use interrupts (for simplicity and to keep the board in a relatively clean state after boot).

I then used that library and built a working bootloader (called Airboot) that does both serial + OTA programming without a flash chip.

Will post it as I clean it up a bit more.

[Felix]

zingbat,
Awesome, looking forward to seeing some code!
Also can you please link in airboot, would like to take a look at that.
Thanks!

[TomWS]

I'm looking forward to it as well, but, in my experience, one very important feature of an OTA boot loader is the ability to replace itself (OTA, of course).  Cuz, once you're committed to this path, you need this ability as well.

Another factor to consider is how to address radio differences (433, 898, 915, HW vs W, LoRa?).  Can it be done with a single generic BL or do you need one for each flavor? 

Tom

[zingbat]

I added the ability to self-update the bootloader -- thanks for the prompt. It's certainly super handy as I'm developing the BL instead of making sure I'm always tethered to an ISP programmer.

My plan is to make this usable for the RFM69 family. I hadn't planned on adding LoRa support but theoretically that should be easy to plug in if someone has a simple (and small) library for it.

Next up, I plan to work on optimizing the transfer protocol for performance and error handling.

[ChemE]

Zingbat,

Can we see some code even if it isn't all the way done?

[Felix]

IMHO, and I've said this many times before, considering separation of concerns, I believe radio specific firmware has no place in a bootloader.
Besides all the logical reasons, I can add the fact that once you bake in a frequency in the bootloader, it is dependent on the transceiver it is paired with, which is OK assuming transceiver settings won't change (BIG assumption  ), but will obviously require separate compilation for all possible transceivers and settings, virtually endless combinations.

The original Dualoptiboot is designed to be radio hardware agnostic, will work regardless how you choose to transfer a new sketch to the node, be it RFM69/FSK or LoRa, or even wifi or whatever. The settings change in the sketch, not in the bootloader, which is unaffected and is not required to change sets of settings separately from the sketch settings. Another problem with having this tandem settings in BL+sketch is being able to reboot from the sketch (via radio) to get into the bootloader, which then has to be at the right settings for the incoming sketch, then decide how long it waits etc etc etc. Lots of complications.

The "downside" to keeping Dualoptiboot hardware agnostic is requirement for external temporary storage for the incoming replacement sketch (the FLASH-MEM), which some people seem to object (adds cost, +1 to BOM), ignoring the fact that a secure+complete+integral transfer of a new sketch is REQUIRED before starting a replacement. This may be OK in some or even most cases where there is no risk for interference, or where physical access is acceptable fallback if concurrent transfer+rewrite fails.