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.
This is great news! Good progress! I think it would be worthwhile, maybe in a different thread, to resume the discussions WRT some means to programmatically identify the type of radio mounted on the board. There was some discussion about this a while ago, but no conclusion was reached.
The radio doesn't have a useful id to distinguish between HW & W or frequency and this really matters on the setup being used. I don't know about LoRa, but we still need to cover generic RFM69s. I had suggested a small eeprom (SOT-23 footprint) that could be mounted on the board at the same time the radio was, which, even at 64 bits, would have enough info that a generic BL (And RFM driver) could use to properly configure the radio.
Joe had done some research whereby he could monitor self-heating of the radio under certain conditions to determine if it was W or HW, but I'm not sure if he came up with anything conclusive and you're still stuck trying to determine the proper frequency.
You could have a radio/frequency specific BL, but that is kind of messy if you have a mix of W & HW in a network.
If anyone thinks this is worthwhile pursuing, I'd be happy to move this to a separate thread.
Finally, I understand ChemE's enthusiasm, but having worked on numerous SW development projects, I highly recommend that, if you do collaborate with others, keep the team small and use PM to keep the detailed code contained to a small set - 'public' publishing of unfinished code will bog you down trying to keep all the variants in sync.
