In short, using the Arduino 2.3.2 IDE to compile and download the ‘blinking LED’ first example for the ESP32-S2 THING PLUS the build time is 17 seconds (second and subsequent times) and the resulting download is 234 kilobytes(!) which takes a similar amount of time to send to the device. So an iteration such as changing (say) one of the delay times takes the best part of a minute to get to the device, which is absurdly slow.
In contrast, another user posted in the above discussion yesterday that
“Compiling blink first time for ESP32 dev module took 30 seconds, second time it took 10 seconds; size of bin file was 170kB. For AVR (board package version 1.8.3) the times were 11 and 1 second and the size of the (hex) file 2.6kB. Upgraded the ESP32 board package to 2.0.6 … first compile took 70 seconds, second compile took 26 seconds; size of bin file 230kB.”
which indicates that the problem is in the ESP package/libraries because the numbers for the AVR board are as one might expect (sub-second build and small download).
Any suggestions on how to get the ESP numbers down to sensible vales (i.e., similar to the AVR numbers above)?
On an AVR the final code is just the result of the compiled sketch. It controls the complete processor and direct access to all resources. Nothing more, nothing less.
On most other / newer platforms (like ESP32) next to the compiled sketch a complete operating system is uploaded (like RTOS or MBED) which includes many functions (e.g. multi-tasking, extensive debug capability, memory management, interrupt handling, etc etc.) that your sketch might not be needing. You can now do many more functions from a sketch in parallel ( e.g. Wifi or Bluetooth) The sketch-compiled code is now using API calls to the operation system to get its job done or access the resources.
To speed up the compile processor often most of the operating system code is pre-compiled and provided as a library. So when you compile your sketch, the code of the operating system can be linked in.
BUT… all this makes the final code to be uploaded much larger and sometimes also the execution slower due to the overhead the operating system brings. While there is an impact on the execution time… the newer processors are MUCH faster and have MUCH more memory than AT328P chip.
It is the old story when Intel processors were getting faster and Microsoft Windows needed more and more resources.
To show it is not only ESP32, take the new UNOR4 the HEX file is 154KB or the Apollo3/Artemis on with V2 (includes MBED) is 398K just for blink.
OK, thanks. That is much as I expected, although I am sure it should be possible to have a much smaller download to blink a LED for the ESP32 given that it already has a RTOS in place. So the compile should be faster and the download be smaller than the AVR case.
So the question is perhaps better rephrased as:
What changes can I make (or settings that I should change) to get an acceptable compile time and download size for ESP32?
I simply am not going to embark on developing a substantial new piece of code if every iteration is going to take about a minute (and presumably more as I add function). Or, to put it another way, the software that Espressif provides (I assume they are the source of the code) is not fit for purpose. Sparkfun, I trust, can raise this with them and achieve a result that an individual cannot.
Google on “esp32 reduce binary size” or “esp32 reduce compile time”: there are many articles about these. But there is no real solution offered.
You can try a faster PC, more memory, and even faster SSD and that might impact the compile time but not to the extent you are looking for.
Maybe the only way forward is to look for a different board & library that does not generate a large binary… maybe an AVR is the right solution for you but maybe not.
Personally, I don’t mind the compile time or size of binary it is also a good moment to walk away from the screen and give the eyes some rest
OK, thanks. But even if I had a faster PC it wouldn’t improve things much – the download time is longer than the compile time (by a second or two); the total (on second and subsequent time) is around 40 seconds wall-clock time.
In contrast, compiling & linking my PanGazer application for Windows is 62 seconds on the same PC. That’s compiling it all from scratch: 36,000 lines of C and C++. Normally, of course, only one or two source files need to be compiled, which is less than 5 seconds per iteration. This in turn means that each change can be smaller (I edit the change and corresponding test case at the same time – often just a few lines of code) which in my experience is much more efficient and less error-prone than doing larger changes. But that is only true if the cost of an iteration is less than the edit time.
