Add OTA Update capability

[dirtbit]

Dear eamars - first of all: Many thanks for your engagement on this project and also sharing this with the community. This is very much appreciated!

This patch provides an OTA update feature by implementing @usedbytes picowota bootloader. I hacked the bootloader (https://github.com/dirtbit/picowota) that way it can use streamlined OpenTrickler EEPROM routines to extract previously via OpenTrickler web interface configured WIFI credentials or it creates an own AP. AP credentials can be modified in CMakeLists.txt.

There're two downsides:
1: Because there's no solution known yet for sharing cyw43 lib between app and bootloader, it requires to be linked twice and the bootloader is getting about 400 kB in size. As we have, after implementing this bootloader, still >43% of free flash, I consider this as a "future problem".
2: merging the two .elf files requires ELF2UF2 & PIOASM tools built by OS depending compilers. Especially on Windows, if one does not install the Build Tools for Visual Studio with "Full "Windows 10 SDK", these are typically missing -> https://vanhunteradams.com/Pico/Setup/PicoSetup.html. One then needs to manually grab them from i.e. https://sourceforge.net/projects/rpi-pico-utils/

Please excuse this contribution is focusing on Windows users.

[eamars]

Hi @dirtbit
First of all, thanks for your time and effort putting into this project. I really appreciate for your code.

My only concern is the use of serial-flash. Keep in mind the user of the OpenTrickler might not be the tech guru, running the command line tool can be challenging and prone to error. In this case my preference is to rely on the web interface for all non-trickling operations. Thus below are my thoughts:

Flash memory address layout

Flowchart of the upgrade routine

I'm more than happy to open to discussions. Thanks again for your work!

[dirtbit]

Hi @eamars

Understand your concern, for users convenience it makes perfectly sense to not use a geeky update tool.

Personally, I do not recommend to split the flash into bank 1 / bank 2, as the application per today is almost at 1M and this would definitely limit implementing further features.

Honestly, if we should get rid of the serial-flash tool, I think we'd have better usage of the memory if we'd integrate pulling of the new binary from web or local & "serial-flash"-functionality into the bootloader itself.
This way, today's web interface could take over the functionality of checking for update, guarantee Confidentiality (who is authorized to change data) and start bootloader while handing over a pointer to the new binary to pull it from. I could also imagine the bootloader serves as a web interface to load a local binary in case no pointer is provided and grants Integrity (is the data valid).

From technical side, one of the big challenges will be to directly pass received data to the flash, as Pico's RAM is only 256 kB and we will not be able to store the entire binary in RAM. That's also the reason why I think the bootloader would be responsible for handling the binary. Unfortunately, I have doubts that we can pack all above into a reasonably small bootloader (i.e. 0.5M), also given the fact we have to link entire cyw43 into the bootloader.

Summary: As we're pretty limited in RAM and Flash, I think without tremendous efforts to shrink code or build on new hardware (by adding external Flash or switch to the bigger RPi Zero), the provided solution is the optimum we can get, although it has some downsides.

Nevertheless, I think implementing a "Hey, new firmware available!" to the OpenTrickler's web interface, maybe even including the download link of a pre-built binary, is already a good starting point. How the binary is then flashed is the decision of the user - either "old school" via USB bootloader or serial-flash.

Please let me know about your thoughts.

[eamars]

Thanks! I will take a look and evaluate once the profile change is implemented. Thanks for your contribution!