One way of dealing with this would be that if this setting is changed, the board saves the setting. Then a reboot - is forced - so the system then starts with the new setting?
Yes, that sounds like a good plan.
How about undefining the BLE var ? ... the exception could have a help message?
I'm not sure how we'd do that without modifying the interpreter internals (especially the help message). It's also likely someone may have retained a reference to the function - eg var go = NRF.findDevices.bind(NRF,myFunction).
I don't think it is unreasonable to reboot on a config change if you free up a heap of memory in the process.
Totally - or even just display a message saying Now call ESP32.reboot() for changes to take effect
Just a quick gotcha here: save() saves an image of RAM to flash - if you save a large image and then load it when you have less RAM something will break. You probably want to call jsfRemoveCodeFromFlash whenever you change BLE to avoid this (or you could remove just SAVED_CODE_VARIMAGE - but there's no special function for this AFAIK).
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Yes, that sounds like a good plan.
I'm not sure how we'd do that without modifying the interpreter internals (especially the help message). It's also likely someone may have retained a reference to the function - eg
var go = NRF.findDevices.bind(NRF,myFunction)
.Totally - or even just display a message saying
Now call ESP32.reboot() for changes to take effect
Just a quick gotcha here:
save()
saves an image of RAM to flash - if you save a large image and then load it when you have less RAM something will break. You probably want to calljsfRemoveCodeFromFlash
whenever you change BLE to avoid this (or you could remove just SAVED_CODE_VARIMAGE - but there's no special function for this AFAIK).