Two beginner's questions (WiPy 3 vs pyboard)

[mathieu]

Hi all,

I'm intrigued by the WiPy 3, but my first impression is that the documentation is rather cryptic. For instance, the spec sheet lists I2S, but I've not found the corresponding documentation. I'm wondering if the WiPy is at least minimally mature and usable for practical purposes, or if everything is very much in alpha phase? Any pointers to good documentation/tutorials would be particularly welcome.

On a related note, I'm note even sure how the latest WiPy compares to the latest pyboard in terms of CPU and RAM? Is one significantly better/faster than the other?

Thanks and sorry for the noob questions...

- Mathieu

[pythoncoder]

Whether the Pyboard is better depends on your application. The Pyboard has no network interface so if you require network connectivity your choices are either to use the Pyboard with a network adaptor or use one of many ESP32 or ESP8266 devices. WiPy 3 uses ESP32.

I can't comment on the maturity of the WiPy 3 as I have no experience. I have used other ESP32 hardware using the official MicroPython port and its associated vendor firmware. My view is that this environment is not yet fully mature. It's possible that PyCom are ahead of the pack here. You'll have to form your own judgement on their documentation and support.

If you don't need network connectivity the Pyboard is (in my opinion) the best. Its documentation is excellent, as is the support. It has considerably better real-time performance because it doesn't need to support wireless processing in the background. So if you plan to work with electronic hardware using interrupts the response time is very much quicker. It has great low power modes - I have Pyboards which run for over a year on four AA cells. It is highly reliable and mature: some of us have been punishing it for three years or more Its support for SD an card means that it can have a large filesystem.

Alas as far as I know none of these options have working I2S. @blmorris started work on a Pyboard implementation some time ago but never completed it. The physical hardware on the Pyboard has capabilities which are as yet unsupported by MicroPython.

[mathieu]

Thank you for your answer, pythoncoder, it was helpful.

May I further ask if the following statement:

If you don't need network connectivity the Pyboard is (in my opinion) the best. Its documentation is excellent, as is the support. It has considerably better real-time performance because it doesn't need to support wireless processing in the background.

also applies to boards such as the Sparkfun ESP32 Thing (https://www.sparkfun.com/products/13907), or only to boards where WiFi seems to be enabled by default?

Thanks again, I'm sure I'll have more newbie questions soon.

- Mathieu

[pythoncoder]

The Sparkfun ESP32 Thing uses an ESP32. All ESP32 and ESP8266 boards have an underlying OS which limits performance. On the Pyboard (and other STM boards) MicroPython runs on "bare metal". There is no underlying OS to steal CPU cycles. Interrupt latency is greatly reduced and code timings can be made very repeatable.

[loboris]

All ESP32 and ESP8266 boards have an underlying OS which limits performance.

I don't think this is entirely true.

If WiFi is not started (or other FreeRTOS tasks), almost nothing runs under FreeRTOS and the impact on performance is minimal.
Interrupt latency is certainly better on STM boards, but if you are using interrupts to start some Python function, the difference is minimal as the latency in scheduling the Python task is much bigger.
There are also functions to stop other FreeRTOS tasks and get the excusive use of the CPU.
Many peripherals on ESP32 have very precise timings and can be used in places where the STM board will use CPU loops.
For example, the neopixel timings will always be more precise on ESP32 (if using the RMT peripheral where the precision can be as low as 12.5 ns).

There are situations where STM boards will run better than ESP32, but with clever programing and using of ESP32 peripherals, ESP32 boards will often run better.

Of course, it all depends on what are you using the MPy board for. I don't think STM32 and ESP32 MicroPython boards are directly comparable.

[pythoncoder]

Thanks for that interesting and informative reply.

Unlike yourself I'm no ESP32 guru but there are some interesting references to poor interrupt latency on the Pycom forum and on GitHub, notably the comment from @Robert-hh on RAM caching. In some situations a fast response to a hard interrupt is vital where hardware needs to be serviced. From reading and from my own tests the worst-case hard IRQ latency seems to be well over an order of magnitude slower than the Pyboard.

Clearly if the hardware ISR then launches a soft IRQ or schedule a uasyncio task then we're talking (relatively) slow time on both platforms and I doubt there's much difference between them.

I haven't tried your port yet but it's definitely on my todo list...