MicroPython Startup Time

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
paulg
Posts: 29
Joined: Fri Oct 23, 2015 1:06 pm

Re: MicroPython Startup Time

Post by paulg » Wed Dec 11, 2019 10:56 pm

OK, so the web site is wrong. Perhaps someone should update it.

User avatar
jimmo
Posts: 2015
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: MicroPython Startup Time

Post by jimmo » Thu Dec 12, 2019 2:58 am

paulg wrote:
Wed Dec 11, 2019 9:11 pm
So where did the 150us come from? Could it be that Damien made a mistake and nobody thought to question it or double check it?

OK, so the web site is wrong. Perhaps someone should update it.
I suspect that the quote on the website is measuring MicroPython itself. i.e. the time taken from when the first bit of MicroPython code starts executing to when it's ready to load boot.py.

Indeed, if you measure it, it's approximately 160us. I used systick (via mp_hal_ticks_us) to measure main.c from when the clock is active to when it's about to execute boot.py.

Then five things things happen:
- It loads boot.py from flash (this is several flash ops)
- It execuites boot.py (if I add "import time; print(time.ticks_us())" to boot.py I see about 5500us)
- It initialises the USB stack
- It loads main.py (more flash ops)
- It execuites main.py

With empty boot.py / main.py this takes about 50ms (i.e. cold boot to REPL over USB).

So perhaps the wording should be clearer to indicate that it doesn't include the time to actually load boot.py from flash? But then it wouldn't be a very useful number because it's just dominated by the flash time.

User avatar
Roberthh
Posts: 2236
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: MicroPython Startup Time

Post by Roberthh » Thu Dec 12, 2019 7:29 am

@jimmo Specifying an internal time before some user script can take control is of little value.For people using a device, e.g. in the OP's application, the total time until her/his code runs is important. If access to the files system is a bottelneck, the comment of @pythoncoder about frozen files and one of the recent changes to freeze boot.py and main.py are good hints to shorten the boot time.
But still, the complaint was about ESP32 and its 1-2 seconds boot time.

User avatar
pythoncoder
Posts: 4674
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: MicroPython Startup Time

Post by pythoncoder » Thu Dec 12, 2019 9:42 am

Roberthh wrote:
Thu Dec 12, 2019 7:29 am
...
But still, the complaint ways about ESP32 and its 1-2 seconds boot time.
Indeed, and that has a whole RTOS to boot, presumably before MicroPython gets a look-in.
Peter Hinch

User avatar
rcolistete
Posts: 328
Joined: Thu Dec 31, 2015 3:12 pm
Location: Brazil
Contact:

Re: MicroPython Startup Time

Post by rcolistete » Thu Dec 12, 2019 1:54 pm

It would be nice to have a compilation of some MicroPython boards with :
- time to wake up from deep sleep before starting to run "main.py" (during the "main.py" it is easy to measure the active time with software);
- plot of i(t) x t in mA for this period, so the real mean electric current can be calculated.

Because this information is important to estimate the battery autonomy of projects using deepsleep.
My "MicroPython Samples". My "MicroPython Firmwares" with many options (double precision, ulab, etc).

User avatar
RWLTOK
Posts: 47
Joined: Thu Dec 14, 2017 7:24 pm

Re: MicroPython Startup Time

Post by RWLTOK » Sun Jan 19, 2020 11:31 pm

I built V1.12 for the NUCLEO_L452RE board. When I reset the board, it is nearly 10 seconds before a promt appears. I checked this with a logic analyzer to prove that it was not a delay from WinDoz. Thoughts anyone? For what it's worth, I used whatever compiler you get with a apt-get install gcc-arm-none-eabi on Ubuntu 18.04 and not the latest version 9 that came out last Novemer from ARM Ltd.

Code: Select all

MicroPython v1.12-68-g3032ae115 on 2020-01-19; NUCLEO-L452RE with STM32L452RE
Type "help()" for more information.
>>>
Thanks

Rich

PS: With the same build environment, I created an image for the PYBV11. Here is the output. It responded to a reset in the normal quick time.

Code: Select all

MicroPython v1.12-68-g3032ae115 on 2020-01-19; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>>

User avatar
Mike Teachman
Posts: 94
Joined: Mon Jun 13, 2016 3:19 pm
Location: Victoria, BC, Canada

Re: MicroPython Startup Time

Post by Mike Teachman » Mon Jan 20, 2020 1:43 am

Here's another datapoint for the discussion

Lolin D32 ("regular" ESP32) board. MicroPython v1.12. ESP32 @240Mhz. I used an oscilloscope to measure the startup time.

Startup time = time between rise of the Reset signal and rise of a GPIO pin (which the first MicroPython code that runs).

Startup time, 800 LOC in main.py: 2.5s
Startup time, 800 LOC in frozen mpy: 600ms

paulg
Posts: 29
Joined: Fri Oct 23, 2015 1:06 pm

Re: MicroPython Startup Time

Post by paulg » Thu Jan 23, 2020 8:45 pm

Mike, thanks for the datapoint.

Am I right in thinking your board does not have any SPIRAM?
Do you have the startup time for non-frozen pre-compiled bytecode?

User avatar
Mike Teachman
Posts: 94
Joined: Mon Jun 13, 2016 3:19 pm
Location: Victoria, BC, Canada

Re: MicroPython Startup Time

Post by Mike Teachman » Fri Jan 24, 2020 1:55 am

Right, no SPIRAM. Sorry, I didn't make any timing measurements with non-frozen mpy files. I'm curious now .... I'll try it tonight.

User avatar
Mike Teachman
Posts: 94
Joined: Mon Jun 13, 2016 3:19 pm
Location: Victoria, BC, Canada

Re: MicroPython Startup Time

Post by Mike Teachman » Fri Jan 24, 2020 6:06 am

I ran some more startup time benchmarking tests with two ESP32 dev boards:
  • Lolin D32 (non-psram)
  • Lolin D32 Pro (4MB psram)
startup time = rising edge of reset to rising edge of GPIO pin

MicroPython program is 798 LOC

Lolin D32:
main.py in filesystem: 2.85s
main.mpy in filesystem (not frozen): 1.31s
main.mpy frozen: 660ms

Lolin D32 Pro:
main.py in filesystem: 4.44s
main.mpy in filesystem (not frozen): 2.54s
main.mpy frozen: 1.80s

For my current project I'm using an external watchdog timer with a minimum timeout spec of 900ms, so I need a startup time less than this amount, or the watchdog timer will pull the processor into reset before it can be serviced. The only combination that satisfies this constraint is the non-psram board with the main application code frozen ...
Last edited by Mike Teachman on Fri Jan 24, 2020 2:12 pm, edited 1 time in total.

Post Reply