Is micropython more stable on any particular platform?

[IcedRooibos]

On the old forum (link) there is some talk about platform maturity. However the post is a little dated by now.

I was wondering if micropython is more stable/robust on any particular platforms? And what does that actually mean - what would be the difference when picking different platforms to build on?

Personally I am more interested in the choice between STM32 and ESP32 but a general discussion would be interesting too.

In general, my opinion is that ST devices are more robust and reliable. Further, the MicroPython port is more mature than on the ESP32.

Mature uPython based on STM32F4 platform is very reliable but an ovekill for smaller application nodes, particularly when you have to add reliable wireless connectivity solution to it.

I backed ESP8266 uPuthon development on Kickstarter, but have given up on it completely now. I don't have time to fight with its various limitations and reliability. Not blaming uPython, but the platform itself has limitations and issues, adding uPython to it makes it worse. Anyway, may be just my opinion.

ESP32 has lot more potential as a uPython platform than ESP8266 but it is still in early stages of development to be considered stable and reliable for serious applications. I am concerned about lack of direction or future roadmap for this platform from Damian and MicroPythons pont of view? Development is now fragmented through various branches Micropython, Pycom, LoBoris and unfortunately not fully compatible. Have been playing with all 3 options and they all have issues to be considered stable and reliable.

[jimmo]

Much of what was said on that forum thread is still true today.

But the answer is nuanced -- I think @peterhinch made probably the most important point: "It's crucial to separate the language from the platform."

MicroPython the language is very mature at this point, and the language has very few differences between platforms, except for features that are removed on chips with smaller ROM. (The sort of differences that exist are really low level things like how exception handling is implemented for the specific architecture, or of course the native code generator used by @native / @viper).

There are lots of things that vary between platforms.

• The reliability of the chip
• The availability of the chip (this might actually be the biggest factor right now with that whole chip shortage thing!!)
• The maturity of MicroPython's support for the various peripherals provided by that chip
• The support, maturity, complexity, and reliability of the vendor's SDK/HAL
• Complicated interactions between different features of the peripherals and SDK.
• How you use the chip in your design (e.g. with or without external flash, external RAM, etc)

The ESP32 is an amazing chip, and the S2/S3 (and C2/C3) series have extended it in all sorts of interesting ways. It's a very convenient way to do both WiFi and BLE That said, the ESP IDF is an incredibly complicated piece of software. It's much harder to make reasoned arguments about how things work and how they interact. It's also very integrated -- the WiFi and BLE share resources with the main CPU, not to mention that there are two CPU cores. Also it runs an RTOS (FreeRTOS), which makes it harder to reason about exactly when things happen, e.g. it means that IRQs in MicroPython are "soft" not "hard" (see https://docs.micropython.org/en/latest/reference/isr_rules.html).

The ST port is conceptually much simpler - there's no RTOS, it just uses the ST HAL (and mostly the LL HAL). In terms of support for processor features, ESP32 and STM32 are quite similar. STM32 has USB support.

I assume because you're choosing between ESP32 or STM32 then you must need WiFi or BLE. ST don't have a WiFi offering, so as far as MicroPython goes (unless you want to write your own drivers), you pretty much need to use either an ESP32 coprocessor running Nina, or an Infineon CYW43 (as featured on the Pico W, Portenta, and Pyboard D).

ST have the STM32WB family for BLE. These are well supported by MicroPython and I am aware of a few different commercial projects using it. The other alternative is of course an external HCI controller (e.g. dedicated part, or other options like an nRF5x running Zephyr or NimBLE Controller). The advantage of an external controller is that it dramatically reduces complexity by separating responsibilites. (Coordinating the STM32WB's wireless coprocessor core was not simple, not to mention firmware loading etc).

Both ESP32 and STM32 support Ethernet (either with built-in MAC or external). The STM32 Ethernet support in MicroPython has a lot more "production hours".

The RP2040 is an interesting one. In terms of supported chips for MicroPython it's a clear stand-out in terms of how transparent and understandable the SDK is. On the other hand, multi-core adds a whole range of extra complications (although you don't have to enable the second core, in which case it has zero impact).

One thing that comes up a lot in forum discussions is around how the various chips manage flash and how this impacts operation latency. This applies to both code execution and the MicroPython filesystem. For example, a design that shares the same flash (internal or external) for both code and filesystem, will be unable to execute code while erases are in process (e.g. ESP32 in most designs will be like this). But using internal flash for code, and external flash for filesystem will avoid this (the Pyboard D does this).

(This is a good question, it's hard to give specific answers though without knowing more about what your application needs. Keen to see thoughts from others)

[peterhinch]

That is an excellent overview. One extra point re platforms is that of interrupt latency. STM32 and the Pico/Pico W are excellent in this respect, with a Python interrupt service routine (ISR) running about 10μs after the interrupt. By contrast Espressif chips support only soft interrupts. Latency is up to a few ms; in systems with SPIRAM it can be 100ms. This is an absolute deal breaker in some applications.

[IcedRooibos]

Thank you for such a well thought out and detailed reply, Peter and Jim! Since this question comes more out of curiosity than anything else it's hard for me to provide more details about the "use case" but it's really helpful to learn about some of the nuances you have highlighted here.