MicroPython's maturity and future

[starstuff]

Hi, I have a question about MicroPythont's future and current status.

In the past I've used Espressif AT-Commands and C++, NodeMCU and LuaNode with the espressif chips and others. I'm new to MicroPython and I'm beginning to like it... a lot but I'm a little bit confused as to the maturity of the MP project.

Can someone with inside information (developers, power users etc) bring me up-to-date on the completeness/maturity of MP? I know that 100% complete is impossible since all languages are constantly evolving but how would you describe MP's status? 30%, 50%, 80% complete? Ready for businesses use, mission critical?

The reason I ask is because I have code running on ESP8266 and that very same code won't run on the ESP32. Some functions that are present on the ESP8266 build are not present on the ESP32, for example the uos.dupterm and other. I think that the strengths of MP is the inter operability between boards and chips.

I'd like to hear your comments and experiences in this respect.
Thanks
robert,

[pythoncoder]

The different MicroPython ports have varying levels of maturity. The most stable and fully developed is the STM port as used on the Pyboard. The ESP8266 port is now stable, but a year ago it was prone to crashes and reboots. The ESP32 port is more recent - I haven't yet used it but I'm not surprised to hear that there are unimplemented features.

So I think the question is best raised with reference to a specific port. My personal view is that the STM port is suitable for commercial use.

As for true inter-operation between ports that is some way off. The aim of the machine module was to provide a common hardware abstraction layer but the module is incomplete. The pyb module offers access to STM-specific functionality which is not available in machine.

[deshipu]

Also be warned that the whole thing is still very much in flux. We had a code-breaking incompatible API change as recently as last release, and many parts of the API are still undocumented, which means that you can't really use them without knowing if they won't change soon.

[pythoncoder]

The pyb module and the STM port is stable as far as I'm aware.

[stijn]

Can't speak for the board ports, but unix and windows ports are, in my opnion, totally ready for production use. The core is likely rather bug-free. Whether they're mission critical is something else and depends on application type. We have an application which must consistently run for hours and hours without any problem whatsoever, and does so every weekday on 10+ different machines. Our frontend pythons scripts are between 200-2000 loc and the custom C/C++ backend modules are >10k loc. No real problems in the past year.

[Roberthh]

@stijn Why do you use MicroPython on Windows and Unix machines instead of standard Python?

[fpp]

...and in addition to Roberts's question, are those OS-ports functionally equivalent to the STM reference ?
For instance, does the USB-HID device stuff work the same in Linux ?

[dhylands]

I don't believe that anybody has written USB-HID support for the unix port. It would be a totally different implementation since it would need to use the linux USB driver, where on the STM port, the code talks directly with the hardware.

On other microcontrollers, USB HID can generally only be supported if the microcontroller has support for it (the ESP8266 doesn't have a USB peripheral - for example).

[starstuff]

@pythoncoder

Yes, not having the same development progress (esp8266-esp32) is what I thought, we'll have to wait for all ports synchronize.

Thanks to all that responded and offered comments and information.

[pythoncoder]

@fpp The Unix build doesn't include hardware drivers any more than does CPython. Its purpose is to test and debug generic MicroPython code and to port standard Python to MicroPython. It's also useful for reporting bugs in MicroPython: if a test script fails under the Unix build it will probably fail under all ports.

@stijn I too am puzzled why you use it for production code. CPython is designed to run on a PC. It's faster because it's optimised for speed whereas MicroPython (as the name suggests) is optimised for size.