MicroPython Forum (Archive)

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

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.

@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.

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.

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.

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.
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.

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

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?

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.

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 ...