Latest version draws too much energy - seems that WiFi is enabled by default

[elFallino]

I updated today and now the esp32 fails to boot. It seems that the FTDI adapter can not provide enough energy.
I already had that problem before (with previous versions of this plugin) as I tried to run a sketch that uses WIFI without additional power source.

So I guess that the latest commits enable WiFi by default. In that case I think that WiFi should explicit be enabled by user code.

[me-no-dev]

the stack is not started, just the radio. You should not power the esp from FTDI though. Get a proper LDO to 3.3V

[elFallino]

I added a 3.3V buck converter, but radio was not started automagically in previous version, was it?
If so, I still think that it would be better to keep radio disabled until user code activates WiFi / BT.

[igrr]

The difference from the previous version is in RF calibration process. Now it takes slightly longer and needs more current.

[clowrey]

The latest version is also running at 240mhz vs 160mhz previously which means it draws more power overall too, I know that will be configurable in the future. My Espressif dev board draws 160ma now from 120ma previously.

Do you have plans/is it possible to have the RF calibration and all radio functions not start up until they are called/initialized by the Arduino IDE? maybe this is already possible from the IDF directly?

[igrr]

There seems to be a regression in the ESP-IDF that wifi initialization only works correctly when it is called pretty early on. Someone (myself or one of my colleagues) will look into this next week. Once we fix this, WiFi initialization can be moved to a later stage, when e.g. WiFi.begin is called. @me-no-dev has already done all the work on Arduino side, we just need to figure out what goes wrong with WiFi init. Once WiFi init is moved from startup code, we can postpone RF init as well.

Edit: ESP-IDF does have an option not to initialize RF in startup code.

[me-no-dev]

The force has been restored!
Do not include WiFi.h and phy will not start.

[clowrey]

Now the dev board only draws 80ma at 240mhz when previously it was 150ma with WiFi always on :)
I have a speed comparison of some different Arduino boards including current build of ESP32 here if you're interested: https://hilo90mhz.com/arduino-esp32-esp8266-101-speed-test-comparison-chart/

[me-no-dev]

Oh this is really good! I can tell I need to optimize pinMode pulls to drop it under 1us :)
What I would really like to see in the table are some STM32 MCUs :) Other than that ESP32 seem to top them all :P

[clowrey]

I'm guessing something changed in the pinMode function since earlier Nov as my previous test shows it 0.526 us even at the lower clock speed.. I was having trouble getting the STM32Duino core working with some STM32 dev boards so cant include those yet.. But I did just add a comparison to the Teensy 3.6 board with NXP K66 Cortex M4 that someone else ran these same tests on. The ESP32 compares pretty well against that chip, some areas are a little slower, some faster. I bet there is room for improvement with some optimization too ;)

[me-no-dev]

yes pinMode has changed because some pins have pull up/down settings elsewhere. I'll try to improve speed there, but some pins will always pinMode slower than others. If you pinMode pins 16 or 17 you will see a difference (closer to what you had before). I can probably run this against STM32F1 board

[elFallino]

Thank you for solving this issue.
Where can I buy you a beer? :)

[me-no-dev]

I live in Bulgaria. You coming by? :D

[me-no-dev]

@clowrey here are my measurements with the latest commits (note I pinMode pin 16 which is not RTC pin) Added a couple STMs

[clowrey]

Great! Can you share the google docs file so I can copy some of the results into my spreadsheet for comparison? It might be neat to create a record of improvements from current to future versions of the Arduino ESP32 core