Loop execution time restrictions?

[davef]

While trying to get programs to run reliably on a ESP32 and a ESP8266,
Google got a hammering especially searching the Micropython forums.

Then I ran across "A Beginner's Guide to the ESP8266" at
https://tttapa.github.io/ESP8266/Chap01 ... P8266.html and he talks
about:
Sharing CPU time with the RF part
especially about loop execution time. I re-read the utime docs and
don't see anything about them blocking so I would like to know ... does
the Micropython port for these devices handle the WiFi and Tcp stuff if
you have long loop execution times?

He suggests that even waiting 750ms for a temperature conversion can get
you into trouble. This is on an Arduino though, so no Micropython involved.

Thanks,
Dave

[jimmo]

does
the Micropython port for these devices handle the WiFi and Tcp stuff if
you have long loop execution times?

The ESP32 and ESP8266 are very different. That article is taking about ESP8266.

On MicroPython for ESP8266 it does this automatically for you, both
- Every N Python bytecode instructions
- While time.sleep_ms / time.sleep_us is running

On ESP32, MicroPython integrates with the FreeRTOS to implement delays and multi-tasking.

[davef]

Thank you for that. I have been trying to get reliable code execution on the ESP32 for the last few months and thought I might be over-looking some not obvious-to-me restrictions.

Cheers,
Dave

[jimmo]

What sort of issues do you see?

[davef]

Hi Jimmo,

I have been getting random "lock-ups" in a datalogging program. I could test test test and everything would work properly but leave it running and 1-7 days later it would "lock-up".

I started throwing try-exception machine.reset() in 1-wire calls, any changes in network access and everyday a machine.reset() after the log was sent and it didn't make any difference.

Following:
viewtopic.php?f=16&t=5517 which is for the ESP8266 I stopped using AP-mode. One hour later it crashed. I have now placed mkiodev's SW WDT example in and it has run 2 days now.

I tried saving a timestamp of when it failed but unfortunately saving it in /ramdisk and having to do a re-boot to get the system running again was not a clever idea.

I have read through some logging examples, so might have to get more serious in my testing. Any suggestions welcomed.

Thanks,
Dave