Before I go further... Is Micropython ready for "production" (ESP32 Specifically)

[cbgrey]

Hello all.

I'm a very recent user of MicroPython while helping a company do a POC of an IoT solution. Like most of you, the main benefit for me is more rapid development in Python vs C++. The POC has gone very well so far and I'm optimistic.

We're developing against the ESP32 which will be used in the final device to be deployed in a commercial setting (thousands of devices).

Before we go further into our dev efforts with MP....what is the general industry feel on using it in a commercial context like this? What problems might we run into as we move from POC to product development? Is MP more than a hobbyists tool? Any specific caveats with the ESP32?

I'm hoping the answer is "MicroPython is totally ready and many people are using it in production already" but I'm interested to hear any potential negatives so we have eyes wide open.

Thanks for your thoughts!
Chris

[Kip]

I remember seeing this a while back:
https://youtu.be/WgpMWEdKuyY
Hope it helps!

Sent from my Pixel 2 XL using Tapatalk

[Hanilein]

Good question - and I cannot speak for the ESP, because i don't use them at all.

But I am working in R&D, developing and producing microcontroller based systems and prototypes with small numbers (<10 devices usually).
We have used Pyboards, Pycom, Arduinos and derivatives, Nordic chips and occasionally Raspberry Pi's (but that's not a micro...) and program in Python, Micropython, C and C++ etc.

Your question unfortunately is not a yes/no one, you may need to dig a bit deeper. And if a language is usable for production is not only the maturity, there are a lot of other questions to ask.

First of all, as we all know, Python is an interpreted language, compared to C/C++, which is compiled. That means, a Python program will need different resources, e.g. more RAM, than a compiled program. And Python is slower. On a Pyboard, an assignment takes ~6.5µs, (which is OK), but string operations or similar things run approx. 100-200 times slower, we are looking here at millisecs. Pointer operations with strings in C/C++ give you a huge boost compared to that.

On the other hand, development time (engineering hours) is much faster in Python, and the flexibility (nowadays called agility) is much higher. We can react to changes, problems and requests way faster, and an update in the field can be as easy as sending an email with a py-file.

The flip-side of the coin is security - the Pyboard is open like a barns door. And then the production cost. When you develop during early stages, you may want to have as much processing power as you can get - the system changes all the time, and nobody wants to get stuck with 'out of memory errors' or not having enough timers or other peripherals in the device.

During development time the engineering hours are expensive - saving 10 or 100 Dollars on a piece of hardware is rubbish, when the more expensive hardware saves at least one hour of engineering time. But that changes, the more parts you produce. When you build 1000 devices, one Dollar saved per device equals a day in engineering costs (well, something like that). You get the picture.

So, the approach may be, to start with a scalable system - a processor for example, that is part of a family with larger and smaller devices. Get a large one that runs Micropython and develop in that language. Do the first prototypes, let the customer test. Progress to a short run series of 10 or 20 boards. Rinse and repeat until the product is stable enough for larger numbers to be produced. Meanwhile investigate if it is necessary to swap languages, and what the smallest processor may be you will need. When producing thousands or even ten thousands of devices, it might well pay off, to swap the language, because the savings justify that. It may not be feasible to develop in that other language straight from the beginning.

To use a picture from the physical world: If you build the first 10 enclosures for a device, nobody would be mad enough to ask for injection molded parts for that, you 3D-print them.
If you produce 10000 parts, you can only use injection molded parts (and it's cheapest), nobody would try to 3D print that.

And at last, one of my favorite quotes from Donald Knuth: 'Premature optimization is the root cause of all evil'. Very true.

Hope that helps a bit.

[stijn]

I can also not speak for the ESP, but since you ask about 'MicroPython' in general it includes the language as well as the board support. As far as the language go I'd say MicroPython is ready for production. There might still be some quirks here and there mostly about CPython differences but by now serious bugs are long gone and I feel it's at the same level as others. By which I mean, just to give an example, it works without bugs 99.9% of the time but it's not guaranteed bug-free. So just like you can now and then find a bug in a major C++ compiler, you can probably find one in MicroPython. But dealing with that is part of doing something in production anway and not MicroPython-specific.

[Roberthh]

@Hanilein: Just as side note: timing an integer assignment on an ESP32 and a Pyboard:

ESP32: ~0.3 µs - 2 µs , depending on constant, local, global assignment; most of the time, sometimes substantially longer.
PYBV11: ~0.34 µs - 3 µs , depending on constant, local, global assignment
PYBD-SF6: 0.1µs - 1.2 µs, depending on constant, local, global assignment

Note: Times edited with various types of assignment.

[jimmo]

Another good video -- https://www.youtube.com/watch?v=YovngSLXoxw

(Again not ESP32, sorry...)

I would re-iterate the points above though about MicroPython core vs any particular hardware port. The language itself is very thoroughly tested, has good coverage, and Damien works on it with a mindset geared towards production use. There's some cool stuff in this talk from 2016 about supporting the ESA using it in space-related applications https://www.youtube.com/watch?v=Zm08hXeuv-I I'm aware of several other companies doing serious industrial and production stuff.

That said -- the ESP32 port certainly hasn't had the attention of (say) the STM32 port. It's also a lot more complicated as there are several more layers. I think it depends an awful lot on what your particular application is using.

I don't know a good way to quantify this thought and it is a vast over-simplication, but if your baseline to compare to is that you wrote your firmware from scratch in C/C++, the three main classes of issues you're going to run into on ESP32 + MicroPython are:

- There's an issue in the way MicroPython uses the IDF for some particular driver etc. Odds are you could have made the same mistake in your own code and without the benefit of the existing exposure and testing that MicroPython has. At least in MicroPython there's a community and support for debugging/fixing.
- There's a bug in the IDF (here's an example -- https://github.com/espressif/esp-idf/issues/4196). You're stuck either way. (And MicroPython might already have seen this and have a workaround).
- (low probability) There's a bug in MicroPython. These are usually fixed pretty quickly.


Another thought, back onto the general "MicroPython the language" rather than ESP32-specific... of the queries that come up related to productionized usage of MicroPython , the two main areas I've seen are:
- Locking down access to code and flash data. For ESP32, might be worth looking at what the Pycom boards / port does.
- GC fragmentation. This comes down to how you write your Python code, and generally shows up consistently in testing rather than in rare cases.