Is micropython ready to be used in commercial projects?

[MrCorsair3]

Hello, I have been focusing on the micropython project for several years now and I can see the progress in this project. But I still have some doubts. In my opinion, micropython can be an amazing tool for high-level programming on a microcontroller, because we have a very good hardware abstraction, data processing, IoT or machine learning (increasingly popular) is a good tool, but...

1. I still cant find good IDE for this language, I can found extension for for example vs code or pycharm but these extensions don't work with every hardware, only with esp8266 etc.
2. How can I make a very complex project if I don't have debugging tools (with breakpoints), this is a question for experienced users, how do you debug a micropython program? By print?
3. Are there ports of popular python libraries for micropython like numpy or pytorch ?

Thank you for your answers and best regards :)

[mattytrentini]

The company I work for has been using MicroPython commercially in medical devices for a number of years. It's a legit choice for commercial projects.

You may be interested in watching @andrewleech's Profiling Pathogens with (micro) Python from PyCon AU 2019 that explains a little about how MicroPython is used commercially by our company.

Specifically to your concerns:

1. Most of the team uses VS Code with mpremote in a terminal window; I find it very productive.
2. A debugger would, at times, be handy. See micropython-lib#499 that is attempting to port PDB to MicroPython. But yes, logging, print debugging and run-time introspection with the REPL is manageable.
3. There are ports of many libraries but often not direct ports. numpy and pytorch are very memory-intense libraries that are unlikely to ever run on an embedded device. But ulab provides some of the numerical processing of numpy and there are some efforts to use trained ML networks (training networks on a embedded device is difficult and not particularly useful). A good start there might be to check out Edge Impulse or Tensorflow Lite which aren't MicroPython-specific but are designed to work on microcontrollers. Generally, the Awesome MicroPython list, maintained by @mcauser, is a good place to look up available libraries.

Hope that helps, and AMA... 😄

[MrCorsair3]

Thanks for your answer. In my opinion support PDB should be one of the more important feature to introduce in micropython. I cant imagine working with modern programming language without debugging system. Today I found very intresting MR: #8767 and video: https://www.youtube.com/watch?v=RRN_ngx01vM

[andrewleech]

I also assumed I'd need pdb / vscode integrated debugging... but I still haven't finished the port because I don't need it this much.
I've been an embedded developer for nearly 20 years and in-circuit-debugging has been essential for every previous project / micro I've used in that time.
With micropython, I do a lot more developing of application modules on desktop with Unix port and test driven development style approaches.

On-hardware testing and running individual modules is commonly with mpremote, mounting the local folder or exec scripts.
Either that or Jupyter notebook, live testing and running code.

Then when the application is bigger, running the whole thing on-device, live logging from repl that you can break into to inspect and run arbitrary code at any time is a real game changer.

Even better, with the fledgling aiorepl in micropython-lib you can have a repl to interact with the application, live, without interrupting the app; I'm finding this far more powerful than old C / gdb style debugging.

Sometimes when I really want a "breakpoint" I'll stick an infinite while mybreak loop into the code and run it with mpremote (no waiting for compile & flash) then when the app is stuck at the loop I'll inspect whatever I want from repl, run arbitrary code to trial things, then break out of the loop manually from repl mybreak=False

[Isaacbg84]

The company I work for has been using MicroPython commercially in medical devices for a number of years. It's a legit choice for commercial projects.

Hello sir, im thinking of using mp too for a commercial product but im concerned about someone just connecting to the serial port and reading the files and ip address. How your company manages this? Did you solve the OTA thing?

Regards

[mattytrentini]

In the field our devices were updated over BLE using OTS (which we implemented in MicroPython) to transfer a firmware upgrade binary to the device.

The firmware was encrypted and signed (using features built into MBOOT).

We disabled the REPL and serial access at the last stage of production. Though it was possible to re-enable it by opening the device and holding a GPIO high with a jumper at boot. We also used frozen code to embed the bytecode into the firmware binary.

A wiki page was started recently that you may be interested in: Securing a MicroPython System.

[aguaviva]

My checklist to determine if a framework is ready for production is:

• check the bug count on Github
• check the number of bug regressions (pick a feature that should be easy to implement, for example I2C and see whether it breaks and how often)
• check whether they follow best practices (coverage of unit tests)
• meat time to fix an issue
• check the open bugs for the features your product will use
• do they rush to support new boards and forget about current or older ones? This will tell you how soon you will become irrelevant
• How did they spend their funds in the past? Will your funding with either time of cash be well spend in the future?

I tend to give an opportunity to MP once a year and every time I conclude it is still far from ready. I see developers working hard but getting very low results, it seems when they fix something but break something else.

A good ovreall metric would be to see 0 bugs open on a simple feature, like I2C, if this is being a challenge, you can imagine the rest is going to be in a worse state.

Sorry for bringing up the bad news but the current approach of things is unsustainable. I would focus on just a few platforms, do less things but do them perfect.

[jimmo]

This is a good checklist! I like to think MicroPython does pretty well on many of these items.

A good ovreall metric would be to see 0 bugs open on a simple feature, like I2C, if this is being a challenge, you can imagine the rest is going to be in a worse state.

@aguaviva There will never be "zero open bugs" against i2c because it's such a common term, there are many bugs that mention i2c that have nothing to do with our i2c implementation. For example lots of board-level things around default pins etc.

I agree, on the face of it I2C might be a "simple feature", but supporting a common interface across so many microcontrollers and families that all have their quirks (and bugs of their own!) is not as simple.

Maybe an example: one of the open I2C bugs is this one: #11834
Using the official API, works on every other ESP32 family except S2, and only fails in a particular situation. I'm sure there's a workaround (but we need to carefully decide whether it's worth the likely days of effort to find and implement the workaround).

We get your point about integration tests (and HIL in particular), of course. As already mentioned in #13436, the core VM, runtime, compiler, etc have extremely high test coverage (though both unit and integration tests) on CI and on real hardware, as well as some features like BLE and networking.

As you mentioned in #13436, #13536 is possibly a good example. Of course integration tests would discover this (although this is slightly complicated by the fact that not all ports support pin assignment like this, but enough do that we should include it). But to be clear, this in no way prevents people from using reliably I2C for most purposes, and I don't think this is a good reflection on "the rest of I2C support in MicroPython". (i.e. this is firmly in the "not yet implemented" bucket rather than "the code is in a bad state" bucket). (And yeah, having a set of qualification tests would provide a much more useful way to quantify the "what is implemented" state of various features).

It is about time the features you care will get broken by some well intentioned developer.

Also note that the bug linked above was not broken/regression, it was just something that was never implemented.

The recent I2S breakage on rp2 was maybe a better example. And note we did have a test for this, but unfortunately only covered the first I2S peripheral. As you can see from the project history, these sorts of regressions are rare -- very few releases have ever had x.x.1 updates.

Anyway, standardising the machine API across ports (to define exactly what is and isn't supported) as well as a corresponding set of comprehensive HIL tests to go with it are two of the highest priorities for this project for 2024 and some of the groundwork for this (moving the Python bindings for the machine API into a shared-across-all-ports version, and unifying pin generation) was finished at the end of 2023.

it seems when they fix something but break something else

Also blanket statements like this aren't very helpful. I think you'll find that while this does happen very occasionally, on the whole it's quite rare.

I would focus on just a few platforms, do less things but do them perfect.

I agree and this would make our lives as maintainers significantly simpler, but unfortunately the reality is more complicated. For example, the funding often comes with the new things.

At this stage the better approach in my opinion is to use some of the time spent on any new thing to "pay back" to the core and shared code such that it's easier to make new stuff "just work". (Refactoring the machine API last year is a good example, we're already seeing the benefit of that with new ports)

[xyzzy42]

A very effective way to reduce bug count is to just automatically close bugs after a few weeks. A certain "open source" ROTS doez this automatic clozing of all reported bugz.

Not only do bug reports just automatically go away without any need for developer time, it has the added bonus that users and non-privileged developers will realize reporting bugs is a waste of time and stop doing it! Which further reduces the open issue count.

[robert-hh]

You forgot the irony tag!
But I know the behavior you talk about. The only "justification" would be, that issues are not severe if they are reported only once. So the might not be important.

[rkompass]

While many of your arguments are justified I think in a professional / production context you would select a certain board and get fully acquainted with it. Then you would do extensive testing of that board and do your own tests of the features you need.
Then you would develop your solution using a certain MP version (that you have tested) and afterwards stay with that MP version in the production.
If you needed features that are not satisfactorily working then you would try to improve MP yourself or ask for help.

With this approach the number of bug reports in this GitHub repo should not be a real obstacle for you.
There are newly introduced boards, boards with changing IDF and catching-up MP versions, changing features (we are not yet at a common set of features and APIs across boards) and users trying something naively reporting a bug, that ain't one.
All this would not bother you with the above approach.
Ideally you would also have a grasp of MPs internals, which many of the developers that use MP commercially seem to have.

Of course we have a big number of boards and a fragmentation of developer efforts across these boards and many many features. This may lead to frustration. Especially given the hype that MP has in the IOT world.
It's simply too attractive to do everything in Python instead of C, hoping that the many problems one had would vanish automatically.
When I tried something with I2C in Arduino 4 years ago I came after much searching/studying the sources to the conclusion that there is quite some half-competent patchwork present there. I had to compile and change sources, recompile and the bug was still there. In MP everything just worked. Of course I did not test whether it would work perfectly on all available boards.
But I could simply use the I2C and immediately got my functionality.
So it may be very often and this may lead to the impression that MP easily usable.
Which it is - until you try something more complicated. Or use a relatively new board or feature.

[aguaviva]

Agreed, but considering the lack of proper quality assurance (QA), it may not be worth investing time or effort in selecting a board. It is about time the features you care will get broken by some well intentioned developer.

[Josverl]

Any dependency on an OSS component will add that risk.
That is why both small and large companies deal with that risk by only consuming components from vetted repos/package feeds, and run their own quality control on that.
That would be no different for MicroPython, than for Cpython,Docker files, NodeJs or Go.

[Tangerino]

I have been using MP for around 4 years and after 2000 devices deployed in the wild ,so far so good. I use Pycharm as development tool with a hal.py file to handle my esp32 and MP specific stuff. Then 99.5% of the code runs on my PC so I run tests etc etc My 2 cents

…

On Tue 20 Feb 2024 at 20:30, Robert Hammelrath ***@***.***> wrote: You forgot the irony tag! But I know the behavior you talk about. The only "justification" would be, that issues are not severe if they are reported only once. So the might not be important. — Reply to this email directly, view it on GitHub <#10715 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYEPRDCYFSLXUHH6F66VADYUT2WTAVCNFSM6AAAAAAUYR52VGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DKMZUGM4DG> . You are receiving this because you are subscribed to this thread.Message ID: <micropython/micropython/repo-discussions/10715/comments/8534383@ github.com>

[aguaviva]

@Tangerino, could you give more info on the devices you deployed?

[AndriiHordieiev]

Can Micropython be used as a platform for teaching programming?

Yes, that's a great idea! There are at least projects:

• Adafruit CircuitPython
• BBC micro:bit
• ESP/ESP32 board
• Pyboard
• Raspberry Pi Pico

There is a simple Mu editor for these boards and many code examples on the Internet.

Can Micropytho be used for rapid prototyping?

I highly doubt it! The fact is that each of the above projects has a rather limited set for working with the internal and external peripherals of the microcontroller. This imposes serious limitations on the ability to use the system right out of the box. You need to look for libraries or write your own for specific hardware or peripheral microcontroller module.

Can Micropytho be used for commercial applications?

Definitely not worth it! Let me list the problems you will encounter:

• Very small selection of microcontrollers
• Lack of description of port capabilities for a specific microcontroller
• Program code cannot be transferred from one microcontroller to another within a series (example STM32L4xx series has different pin names and is not compatible in the set of software modules)
• high requirements for the amount of Flssh and SRAM memory (due to this, the cost of the microcontroller is quite high for mass production)
• there is no easy way to update a large number of devices over the air

[AndriiHordieiev]

Micropython is 10+ years old, but I can't find even 10 successful commercial projects based on it. I'll explain to you why:

This is a diagram of the learning curve in different languages ​​by skill level, so that a successful commercial project could be written based on them.

[stinos]

In other words: "There are only two kinds of programming languages: the ones people complain about and the ones nobody uses"

[aguaviva]

Funny, but show us some serious projects (not temperature loggers) done with micropython.

Facts, not words or jokes.

[stinos]

Put like that, the premise of 'needs x visible serious projects and only then it's ready for commercial projects' is inherently flawed. Unless x is zero, by that reasoning no-one ever would consider it ready.

Likewise the diagram does not make a lot of sense: it's about programming languages. MicroPython implementing quite a lot of the Python standard, it's quite hard to imagine how it could require a steeper learning curve or higher skill level than the behemoth C++ is (and I'm saying that as a rather experienced C++ programmer).

Even if the diagram would be about the MicroPython ecosystem for one particular port or board, i.e. the combination of the language and the port/board-specific libraries, the relative ease of use compared to the alternatives makes it hard to believe.

I'm obviously not saying there are no problems - and from your posts and the wording thereof I take it you happened to encounter some - but there's no need to stretch that to "no it's not ready for rapid prototyping"-like statements which seem rather ungrounded in light of what I see MicroPython being used for (and use it myself for).

That being said, I don't actively follow what others do with it, but the first post here is already a pretty good example. And I have seen quite nice things on the showcase on the Discord channel (IIRC a complete sequencer + GUI recently) and aggregator sites which go way beyond temperature loggers.

And while I can't show my own projects (not open source + NDA for some), I can assure you our 5-10k LOC MicroPython codebase is in fact super serious and is used as a frontend to control a data collection/DSP system, a renderer pipeline, an audio pipeline and various other stimuli presentation mechanisms, and is the backbone on which our scientific (zero room for error there) experiments run and of which the results get published in high impact journals.

[mattytrentini]

The company I work for, Planet Innovation, uses MicroPython for medical devices up to class B. We've been using it for six years and it's been a very productive, reliable language and framework to build upon.

[aguaviva]

A list, show a list of products. (The more specific and clear the answer is the better.)

Plus I don't believe you are doing audio, I tried and had to give up because there are many things broken (i.e: can't do I2S and wifi, yo get lost of missing samples, bug still open) my opinion is that the code is a mess, no unit tests, maintainers prefer to be inefficient and ask for more money.

[andrewleech]

Yes you've made your opinions about what you think of the quality here clear and ignored all responses to the counter so far. I hope it's not your intention but your recent posts sound quite demanding of others to do large amounts of work to satisfy your opinions which is not the way open source works. Just because you tried one thing once and couldn't get it working doesn't speak to everyone else's experience.

The micropython organisation accepts donations which are spent according to the plans of the core team (not me nor other general users).
I'm aware the organisation also does contracted work on occasion for companies who need specific support. No one else gets to make demands for their particular desires.

Please try to keep posted respectful to everyone here, we're all trying to build a supportive community.

I like many / most people who work for companies designing commercial products am not at liberty to disclose specific products we design using a particular platform. Sharing that kind of commercial information requires sign-off from a number of stakeholders. If the micropython organisation approached us with a request to share some of that information I'd start the internal conversations to make that happen, otherwise it's really not appropriate.

[aguaviva]

I tend to ignore the answers that don't address the question, specially if the answers are long and passive-aggressive like yours. So feel free to ignore me as this is not being productive for neither of us.

[andrewleech]

Next to no commercial projects in the market ever publish what coding platform is used behind the scenes!

How many commercial products use stm cube? How many use riot? No one actually knows because this isn't published data.

I know zephyr has a page showing off a handful of products based on it which is nice marketing certainly, but after that who knows.

That being said it would be quite neat to get a similar page for micropython, it's fun to read about other success stories and would help answer questions like this discussion!
The kicker is I believe even the micropython authors don't necessarily know who uses the platform because it's open source and doesn't need registration, so it would take a focused advertising campaign to get companies to reach out who want to be part of such a promo page!

Fwiw I work at Planet Innovation alongside @mattytrentini. As he said earlier we've released a number of products built on micropython. In our case we work on a lot of products and generally have 5 preferred platforms, embedded linux, embedded windows, micropython, zephyr and mobile. Depending on the project requirements we pick which one of these platforms fits best.

Personally I find it much easier to design and architect / structure a larger bare metal project in micropython (add opposed to C/C++), with the ease of module reuse between projects one of its biggest benefits. Asyncio and memory safety are also huge benefits making multitasking much safer and easier than traditional threads.

[ThinkTransit]

We have a commercial product running micropython, although we don't advertise that, as the end customers don't really care what language the firmware is written in.

Our device is a remote monitor for tanks/containers operating offshore and/or in hazardous areas. It is solar powered with GSM and satellite connectivity (via SWARM and ASTROCAST). Our product is also intrinsically safe and IECEX zone 0 certified, which means you can put it inside the fuel tank of your car/aircraft and not have to worry about a fiery death.

It has been deployed in Australia, Europe and South America and we do OTA updates when required.

Would it run faster and be more energy efficient if the firmware was written in completely in C, probably, would the product exist in the marketplace, probably not.

Horses for courses......

insiderassets.com.au