Description
Hi,
I'm just trying to work on the RFM69 FOTA bootloader.
I'm almost done, but when I see in the NRF24 bootloader precompiled hex files, it makes me think that this part will be a mess with RFM69. Why do I think this ? Because we have many customizable DEFINES that can be set on each hardware :
- RFM Frequency (x3 choices)
- HW vs non HW power boards (x2 choices)
- Network ID (set by default to 100, but perhaps 255 choices ?)
- TX power level
- Encryption key
Would'nt it be a better idea to store some of those parameters in EEPROM ?
The logic would then be :
- We set those defines in the sketch code, before compiling and uploading. The EEPROM is at the moment empty.
- At the first boot of the node, when the bootloader starts, it should then read those parameters from EEPROM, if we don't have correct parameters, the bootloader runs the main program.
- When the main program starts, it sets those parameters in EEPROM, so the bootloader can use it when needed.
I know it would consume some more EEPROM (Frequency + HW can be set on the same byte , 1 byte for Net ID, 1 byte for TX Power, 16 bytes for encryption key), but it would allow to keep only a minimum number of HEX files for the bootloader (like the NRF24, 3 hex for 1, 8 , 16 Mhz).
PS : I've just seen that EEPROM_RF_ENCRYPTION_AES_KEY_ADDRESS is already defined in headers files for the encryption key, but no part of the code is currently writing it...
@tekka007, @henrikekblad what do you think about this ?