-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FFat seems to be slower than SPIFFS #16
Comments
Did you try the code before modification? |
Hi Vincent, |
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 Another optimization (that I hope is correctly implemented) is to keep the file open in Hope it helps, |
Hello @Vincent-Stragier Maybe we can add the code to the repo for easy access. I will have to update the android app as well to work with your code |
Hi Vincent, |
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, |
Hi @Vincent-Stragier @fbiego |
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 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 ( @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
The text was updated successfully, but these errors were encountered: