Open Vincent-Stragier opened 2 years ago
Did you try the code before modification?
Hi Vincent, I found this code clean up and modification to be quite stable, no disrespect to fbeigo who has done an excellent job of this project. Vincent I do not know much about FreeRTOS and hence ESP32 tasks etc. But I was wondering if the previous code was increasing speed by swapping between two buffer. i.e. while one buffer is being downloaded the other buffer is being used to write to file. However in the case of " case 0xFC: { // Write updater content to the flash" while the file is being written it does not release callback function until it has finished writing the buffer and hence "case 0xFB: // Write parts to RAM" can not be processed at the same time although I am not sure if write_binary(..) is processed in the background. Anyway if it is blocking then is it possible to write anther task to write_binary so that " case 0xFC: { // Write updater content to the flash" can release and process "case 0xFB: // Write parts to RAM" and process the writing to the file in the background? I do not have enough experience of FreeRTOS to write a that task and I was wondering if you can do that which would improve the download speed. I'd be grateful if you can write this modification. I look forward to your response. Raj
Hi,
@fbiego, I will try to use the FFAT mode, but not right now. I'll keep you inform.
@SuperTankMan, I did modify the code further since last time. @fbiego did a great job of implementing the OTA, the only issue is that it is hard to integrate in other projects (due to the numerous global variables, etc.). In the joined zip, there is a PlatformIO project with the OTA functionality enclosed in a library (feel free to test/modify/use it). Note that the Python script do not complete (probably a bug on the ESP32 side)…
When not using the fast mode, only one slot at a time is used during the upload (I don't know what happen when using the fast mode though)…
I tried to implement the write_binary
function in another task, but it was slower or less stable or both (I do not remember exactly, but I already tried it). The reason of the added delay/instability is that you need a queue to share variable between task, and it takes some time.
Another optimization (that I hope is correctly implemented) is to keep the file open in write_binary
instead of opening/closing it for each chunk (opening and closing files is time-consuming).
Hope it helps, Vincent
Hello @Vincent-Stragier I think this is a great solution and also simplifies the existing code.
Maybe we can add the code to the repo for easy access.
Can you create a PR with your code in a folder named esp32_ble_ota_compact
?
I will have to update the android app as well to work with your code
Hi Vincent, Do you have any updates on the NON Nimble version? The version at the top of this issue?
Hi @SuperTankMan,
I did not manage to work on that issue, I will have more time to do so after the 8th of June.
Best, Vincent
Hi @Vincent-Stragier @fbiego Any updates on the above code at the top? have you forked this in repository? I can see you created one on this repository as https://github.com/fbiego/ESP32_BLE_OTA_Arduino/pull/18 but what about the bare code you sent above? any chances of that one being forked too as its BLE library instead of the NimBLE library?
Hey @SuperTankMan. I believe the program is swapping between two buffers because the ESP32 has a max Global variable allocation limit of around 160KB. It does seem weird to have 2 buffers since they are never used at the same time, one buffer could just be reused instead. Also, since the data isn't being saved to FLASH simultaneously, it seems like the transmission would get faster the larger you set the "PART" Constant. Is there any negative to replacing updater1 and updater2 with one updater that is 65536 Bytes and set PART to 64000? That should cut File IO calls by 4.
Also @Vincent-Stragier, I really can't figure out the point/benefit of running the update as an RTOS task rather than a simple function call. I really don't understand RTOS so I would love to know why I'm missing and why you added them to the code.
Hi @NoelCav and @SuperTankMan ,
In #18, I kept most of the algorithm, which include the updater
“1” and “2”. I planned to use those in parallel, but I do not remember why I did not pursue in that direction. For PART
, it is to be tried. There might be some stability issues.
I see at least two benefits of using RTOS. First, it is easier to integrate to your projects (note that can also be achieved by rewriting the code in a library, like in #19). Second, you are not dependent on the main running task (loop
), which means that if you upload a code that freeze the loop you can still flash the board with a new code.
@SuperTankMan, it is not interesting (and complex) to implement #18 for BLE. I tried, but if I remember well, it was instable and maybe too big. The other issue is that BLE is not supported as well as NimBLE (see https://github.com/nkolban/esp32-snippets vs https://github.com/h2zero/NimBLE-Arduino).
Hi Felix,
I try to run the FFat version of the code, but it looks like it is slower to run... also I have modified your code.
I have heavily modified your code to reduce de complexity (of the firmware and of the Python OTA script). Note that I removed all the code stored in the loop. Nearly all is managed in the
onWrite
callback and a new task is created to perform the update in the end. On the other side I changed the update sequence, I first send the file size, then MTU/Part size and finally I initiate the update by getting the mode. It is not perfect but by removing most of the global variable, the code gets simpler:Best, Vincent