Stability of ESP32 vs ESP8266

[pythoncoder]

...
Any reasons PyBoard D Series is better than ESP32? more reliable wifi? Did you manage to test out the PyBoard D Series?...

I have done a lot of work with the D series. It is streets ahead of ESP32 because WiFi is devolved to a separate chip. This means that MicroPython runs on bare metal and has a fast and deterministic response to events such as hard IRQ's. It is serious professional class hardware with accurate ADC's and DAC's. The SF6W even has a 64 bit FPU for those that need it. On all variants the WiFi handles TLS with ease.

By contrast the ESP suffers huge latencies and DAC and ADC linearity is poor. It's cheap and cheerful, and great for some jobs, but not in the same class in terms of performance. E-type or Morris Minor? The choice is yours.

Re power supplies, powering via USB is fine in principle, but no board will give good service with a toy PSU. Some USB "wall warts" are designed purely for recharging smartphones, a job which can tolerate outages and brown-outs. They really aren't fit for powering kit if you need 24/7 operation. It's crucial to use a unit designed for this purpose by someone who actually knows what they are doing.

[tve]

...
Any reasons PyBoard D Series is better than ESP32? more reliable wifi? Did you manage to test out the PyBoard D Series?...

I have done a lot of work with the D series. It is streets ahead of ESP32 because WiFi is devolved to a separate chip. This means that MicroPython runs on bare metal and has a fast and deterministic response to events such as hard IRQ's. It is serious professional class hardware with accurate ADC's and DAC's. The SF6W even has a 64 bit FPU for those that need it. On all variants the WiFi handles TLS with ease.

By contrast the ESP suffers huge latencies and DAC and ADC linearity is poor. It's cheap and cheerful, and great for some jobs, but not in the same class in terms of performance. E-type or Morris Minor? The choice is yours.

Just to provide a different PoV than Peter, who seems to take every opportunity to bash the esp32 .

The PYBD costs at least 5x more than an esp32 module with equivalent features (voltage regulator, USB interface, LiPO charging). The good news is that you get something for that extra money. The bad news is that it may not matter or you may be able to get something equivalent for less money.

For example, the biggest non-deterministic response I've run into on the esp32 is when mbedtls does the crypto to establish a TLS connection. That can introduce a 800ms or thereabouts hiccup if you use a cipher suite with perfect forward secrecy (e.g. like all the ones supported by TLS 1.3). I haven't actually tested the equivalent on the pybd, but despite "devolving Wifi to an external chip" the mbedtls code still runs on the main uC, thus I don't see how that hiccup would be any different on the PYBD (with the exception of hard interrupt handlers in Py). In fact, on the esp32 it is possible to perform the TLS on the other core thereby eliminating this hiccup altogether.

Some other aspects: the esp32 supports adding a large amount of external PSRAM and modules that have it integrated for a very small addition cost are abundant. What is the equivalent on the PYBD? How about connecting a camera to the PYBD? I have not looked into this, but I don't think it's nearly as easy as with an esp32 and even if the HW supports it I didn't find code out there when I searched (maybe I overlooked the obvious).

The peripherals on the esp32 are not great, the ADC is perhaps one of the worst. Again, the good news is that you get something for the money you pay for a PYBD. You can add a good external I2C ADC chip to the esp32, which adds a comparatively small amount to the BOM.

So overall if money is no object, the PYBD often is a better platform, but not always. If money is an object, YMMV greatly...

To come back to the OP question, having fixed some of the non-blocking socket issues that Peter often refers to I find the esp32 perfectly stable, but I do avoid all boards that have an AMS1117 regulator because it has a very high drop-out voltage.

NB: I'm not trying to bash the PYBD, it's a very neat design, I'm just trying to provide a different PoV than "the pybd is superior to the esp32 in all respects" that Peter wrote.

[OutoftheBOTS_]

What is the equivalent on the PYBD? How about connecting a camera to the PYBD? I have not looked into this, but I don't think it's nearly as easy as with an esp32 and even if the HW supports it I didn't find code out there when I searched (maybe I overlooked the obvious).

most STM32F4 and up have a really good hardware peripheral for using camera called Digital camera interface (DCMI) and is quite advanced compared to how a 8 bit camera with controls lines works on the ESP32. The ESP32 doesn't have a hardware camera peripheral but it does have a 8 bit parallel peripheral with a clock line then using some clever coding with interrupts you can make a work around for the other control lines needed for interfacing with a camera. The STM32 DCMI interface has all this including all the needed control lines built into a hardware peripheral

[rcolistete]

About the comparison between ESP32 x Pyboard D (and STM32) :
- good quality ESP32 board is not so cheap, e. g., TinyPico costs US$20;
- ESP32 hardware and SDK's has/had many instabilities over the last years. See this deepsleep problem, for example :
https://www.instructables.com/id/ESP32- ... -Tutorial/

After a random number of wakes up, the ESP32 goes to sleep and it won’t wake up again. This bug can happen after a couple of wake ups or after 100. It is just random.
One simple solution I discovered is to add a small delay of 500ms after waking up...

- MicroPython with camera ? Go to OpenMV, superb software (firmware + many image/etc functions, OpenMV IDE, etc) :
https://openmv.io/collections/products
you pay more (US$65 for OpenMV H7, US$80 for the Plus version with 32MB of extra SRAM, 5 MPixel camera, etc) but have support from the developers, well documented functions about image/video/processing, yielding a lot more productivity (you save your time);
- without WiFi, there are cheap STM32 boards compatible with MicroPython, like WeAct STM32F411CEU6 Black Pill, about US$4.

Anyway, it is nice to have diversity in MicroPython hardware.

[tve]

LOL, stm32 fanboys come out guns blazing

Good info though. So PYBD-SF2 and -SF3 don't have DCMI, you have to shell out for the -SF6. Or did I miss something looking through the datasheets? Grepping through the MP source, I don't see DCMI camera drivers so you have to code that up yourself, or did I miss something?

I don't think that responding bullet by bullet gets us anywhere, so I'll just say:

Anyway, it is nice to have diversity in MicroPython hardware.

Absolutely!

[OutoftheBOTS_]

It is not so much STM fan boys but more correct information.

I use both ESP32 and STM32, started with ESP32 barbecue of price but ended up mainly using STM32 because of the random ghosts in the machine with ESP32 and also was always running out of pins on ESP32 for my robot projects.

There has been extensive work (far more than what is around for ESP32) for the camera driver on MP on F4, F7 and H7 by the openMV boys and is really well supported on theor own forum.

Also there are now a lot of cheap STM32 around throughout the very extensive range see here an STMH7 delivered under $20US with a connector for a camera on board https://www.aliexpress.com/item/4000844 ... hweb201603_

[cgtan2020]

...
Any reasons PyBoard D Series is better than ESP32? more reliable wifi? Did you manage to test out the PyBoard D Series?...

I have done a lot of work with the D series. It is streets ahead of ESP32 because WiFi is devolved to a separate chip. This means that MicroPython runs on bare metal and has a fast and deterministic response to events such as hard IRQ's. It is serious professional class hardware with accurate ADC's and DAC's. The SF6W even has a 64 bit FPU for those that need it. On all variants the WiFi handles TLS with ease.

By contrast the ESP suffers huge latencies and DAC and ADC linearity is poor. It's cheap and cheerful, and great for some jobs, but not in the same class in terms of performance. E-type or Morris Minor? The choice is yours.

Re power supplies, powering via USB is fine in principle, but no board will give good service with a toy PSU. Some USB "wall warts" are designed purely for recharging smartphones, a job which can tolerate outages and brown-outs. They really aren't fit for powering kit if you need 24/7 operation. It's crucial to use a unit designed for this purpose by someone who actually knows what they are doing.

Thank you so much for your input on this matter.

[cgtan2020]

...
Any reasons PyBoard D Series is better than ESP32? more reliable wifi? Did you manage to test out the PyBoard D Series?...

I have done a lot of work with the D series. It is streets ahead of ESP32 because WiFi is devolved to a separate chip. This means that MicroPython runs on bare metal and has a fast and deterministic response to events such as hard IRQ's. It is serious professional class hardware with accurate ADC's and DAC's. The SF6W even has a 64 bit FPU for those that need it. On all variants the WiFi handles TLS with ease.

By contrast the ESP suffers huge latencies and DAC and ADC linearity is poor. It's cheap and cheerful, and great for some jobs, but not in the same class in terms of performance. E-type or Morris Minor? The choice is yours.

Just to provide a different PoV than Peter, who seems to take every opportunity to bash the esp32 .

The PYBD costs at least 5x more than an esp32 module with equivalent features (voltage regulator, USB interface, LiPO charging). The good news is that you get something for that extra money. The bad news is that it may not matter or you may be able to get something equivalent for less money.

For example, the biggest non-deterministic response I've run into on the esp32 is when mbedtls does the crypto to establish a TLS connection. That can introduce a 800ms or thereabouts hiccup if you use a cipher suite with perfect forward secrecy (e.g. like all the ones supported by TLS 1.3). I haven't actually tested the equivalent on the pybd, but despite "devolving Wifi to an external chip" the mbedtls code still runs on the main uC, thus I don't see how that hiccup would be any different on the PYBD (with the exception of hard interrupt handlers in Py). In fact, on the esp32 it is possible to perform the TLS on the other core thereby eliminating this hiccup altogether.

Some other aspects: the esp32 supports adding a large amount of external PSRAM and modules that have it integrated for a very small addition cost are abundant. What is the equivalent on the PYBD? How about connecting a camera to the PYBD? I have not looked into this, but I don't think it's nearly as easy as with an esp32 and even if the HW supports it I didn't find code out there when I searched (maybe I overlooked the obvious).

The peripherals on the esp32 are not great, the ADC is perhaps one of the worst. Again, the good news is that you get something for the money you pay for a PYBD. You can add a good external I2C ADC chip to the esp32, which adds a comparatively small amount to the BOM.

So overall if money is no object, the PYBD often is a better platform, but not always. If money is an object, YMMV greatly...

To come back to the OP question, having fixed some of the non-blocking socket issues that Peter often refers to I find the esp32 perfectly stable, but I do avoid all boards that have an AMS1117 regulator because it has a very high drop-out voltage.

NB: I'm not trying to bash the PYBD, it's a very neat design, I'm just trying to provide a different PoV than "the pybd is superior to the esp32 in all respects" that Peter wrote.

Thank you so much for sharing your alternative PoV.

[kevinkk525]

That's nice but are there some STM32 boards with Wifi too?
Also it's nice to buy a $4 STM32 but they got no additional SPI flash so they are limited to 256kB which means you need a very special and small firmware of MP to even work with those. Also they are 411 series with only 100MHz.

[pythoncoder]

...
Just to provide a different PoV than Peter, who seems to take every opportunity to bash the esp32 ...

@tve I have no desire to "bash" the ESP32. A Ford Fiesta and a Porsche 911 both have merits. I happen to own the former So I see the importance of low cost and recognise the great work you and others have done on the ESP port. But I also recognise professional quality hardware when I see it.

It is a fact that the interrupt latency of an ESP32 is much worse than a Pyboard D, especially as it doesn't support hard IRQ's. So we are talking several ms if an interrupt happens to occur while a GC is in progress. I gather that with SPIRAM, a GC can take over 100ms. A Pyboard responds to a hard IRQ in (IIRC) about 20μs. That is a huge difference.

Another issue is stability. As you know I've done a lot of work on resilient MQTT. The Pyboard D ran for six weeks without a restart, exchanging nearly 1,000,000 messages. The test would probably still be running if my wife hadn't accidentally pulled the plug to run Christmas lights The ESP32 can't get close, resetting every few days. Testing was done using the same code, in the same physical location and the same power supply.

To be fair the ESP32 has one killer feature for those of us who need fast signals: the awesome RMT interface. I'd love to see support for this fixed and extended.

For some users price trumps performance. Some applications don't care about ISR response and can handle occasional reboots, in which case a Pyboard would be overkill. I welcome diversity, but we should document and recognise these differences otherwise new users will be puzzled and disappointed.

The other reason for supporting Pyboards is that proceeds from their sale keep this whole show on the road. I think those who can afford them should consider buying them.