MicroPython is a wonderful Python interpreter that runs on many higher-end microcontrollers, from ESP8266 to STM32 to the RP2040. MicroPython lets you build devices quickly, and its latest release, 1.23, brings a number of improvements you should be aware of.
The first one is custom USB device support, and it’s a big one. Do you want to build HID devices, or play with MIDI, or do multiple serial streams with help of PIO? Now MicroPython lets you easily create USB devices on a variety of levels, from friendly wrappers for creating HID or MIDI devices, to low-level hooks to let you define your own USB descriptors, with user-friendly libraries to help all the way through. Currently, SAMD and RP2040 ports are supported in this part of code, but you can expect more in the future.
There’s more – support for OpenAMP, an inter-core communication protocol, has received a ton of improvements for systems where MicroPython reigns supreme on some of the CPU cores but also communicates with different systems on other cores. A number of improvements have made their way through the codebase, highlighting things we didn’t know MicroPython could do – for instance, did you know that there’s a WebAssembly port in the interpreter, letting you run MicroPython in your browser?
Well, it’s got a significant overhaul in this release, so there’s no better time to check it out than now! Library structure has been refactored to improve CPython compatibility, the RP2040 port receives a 10% performance boost thanks to core improvements, and touches upon areas like PIO and SPI interfaces.
We applaud all contributors involved on this release. MicroPython is now a decade old as of May 3rd, and it keeps trucking on, having firmly earned its place in the hacker ecosystem. If you’ve been playing with MicroPython, remember that there are multiple IDEs, graphics libraries, and you can bring your C code with you!
Does it have the pointers?
Lets be honest, Python is all well and good as a language… really good to use on a full computer … lots of great libraries… but it has no place in the world of microcontrollers and embedded systems where resources are tight. Also, micropython is able to get types of crashes, within if branches and such, which simply cannot occur in a truly compiled language like C/C++ where the whole source code is checked for typos at compile time. That sort of risk can be handled on a full computer where you’ve plenty of debugging outputs available, but again has no place on a microcontroller trying to autonomously operate a piece of embedded hardware.
You’re just dead wrong. I’ve been using MicroPython since 2015, it’s a wonderful project, the MicroPython interpreter is specifically written to account for microcontroller nuances, and what’s best, both prototyping with it and writing production-ready firmware is dead simple. I have made multiple products, prize-grabbing hackathon projects, and educational tools thanks to MicroPython, not to mention the amount of people I got into microcontroller tinkering through it.
The typos you’re talking about, are simply not that much of a problem, even if you want to have anything run 24/7 (especially due to syntax checks and tools you can use to avoid such problems), and, just like in C, you can write pretty defensively if you need to. Also, if you’re talking risks, you can test your uPy code on a PC with just a few shims. No code is free of runtime bugs, and if that’s a risk for you, you need to take measures either way – not to mention that C is prone to a whole new class of runtime problems that Python avoids.
The cool parts about MicroPython is the sheer speed you can achieve while developing with it, the beginner-friendliness, simpler code due to decreased type handling work and things like dynamic typing, often letting you add a whole lot of features for basically free. I can teach people to build gadgets in MicroPython in a way that C/C++ don’t even come close to, and I’ve done both. Low-level languages have their place, but if you think low-level languages are all there is to it, that’s simply false. There’s a whole class of usecases where benefits of using MicroPython outweigh any benefits of low-level languages, from rapid prototyping to educational to beginner-friendly electronics, and, hopefully, I can write an article or two about it some day.
The other thing is that there is *zero* reason why you have to finish a program in the same language you start it in. It’s ludicrously easy to prototype and debug in MicroPython, and once things are working, swapping over to a C based framework isn’t particularly hard. It’s nice to not have to fight with languages or APIs while you’re also fighting with the hardware.
Of course you don’t have to, either. If there are heavy processing loads needed you can modularize it, compile it, and have that section running uninterpreted.
The one thing that MicroPython provides natively is a way to massively extend a program’s code space, because it’s already interpreted. One dumb trick I created a while ago was creating a ‘storage’ module which allowed you to save data over MicroPython reboots/resets. Then you don’t need to worry about the memory issue – you just do what you need to in one script, then save the output, mark the next script, and reset. Fresh start each time.
indeed! I’ve done a product demo with the test firmware in MicroPython more than once… sometimes it stayed beyond that =D
oh oh and the storage module sounds wonderful! you got the implementation somewhere? would be fun to take a peek!
I’m doing a port of Micropython to an incredibly cheap microcontroller right now, and it’s _so good_. My microcontroller has 512kB of flash and 16kB of RAM, and after system overheads and static variables, I’m left with 10kB of RAM and about 300kB of flash, and Micropython works just fine. It was also really easy to port; everything Just Worked — I went from a basic ‘Hello World’ in C to a REPL in about 45 minutes. It only took a few more days of evenings to get a filesystem in the remaining flash, SPI screen support, GPIO support etc.
Also, just in case anyone hasn’t mentioned it: Micropython allows Python programs to be byte-compiled and embedded into the flash at build time. They then get executed directly from flash. That stretches that 10kB of RAM way further than it has any right to go. Plus, this way you get to run your tests, your static type checker etc all on the PC. It’s great. The only thing it’s missing is an on-board Python debugger.
(Adafruit’s ampy which lets you upload and download files, run programs remotely etc via the serial port and on-board REPL — with no board-specific code required barring a few standard modules — is also worth a mention.)
Highly recommended.
I mean, if you’re not building your own ASIC, can you really say you are computing efficiently?
Teeny little MCUs have a lot of processing capacity. If you spend an dollar per unit on “excess” hardware to get a platform that makes it easier to write and debug that might be a good trade-off.
The Micropython developer experience is wonderfully close to “a full computer where you’ve plenty of debugging outputs available”. The dev team have put effort into this, and it shows.
Finally, it important to acknowledge that while Python is prone to certain kinds of bugs, so are C and C++. For example, use-after-free heisenbugs are not an issue with Micropython. Again, it’s all about making trade-offs.
“.. world of microcontrollers and embedded systems where resources are tight.”
Might not be in that world anymore, Robert. A little Pi Pico has 2 megabytes of flash and hundreds of kilobytes of RAM and 2 cores. I’ve got about a thousand lines of microPython that’s been running on it since December. It has proven more reliable than the grid that supplies my house, although that is a pretty low bar since it’s PG&E.
It garbage collects about once every 5 hours, since it does some stuff, but it hasn’t crashed yet. Longest run was 1025 hours and 50 minutes. I test pretty carefully before I put something into production (that is, move it out into the garage from the desk).
microPython won’t work for every embedded project, but there are ranges of size and performance that it satisfies nicely without much investment in tooling.
I do have some things to complain about with it: The queuing used for the “soft interrupts” does not include the realtime clock in the context, and the hard interrupts seem a little broken on the RP2040; and I have had problems when new microPython images have been released. The implementation of features across the many little machines that it produces is inconsistent, and that is likely unavoidable, but the documentation of which features are *not* implemented on some targets is hard to come by.
I have about 3 more projects that I’m going to write in micropython. Maybe an electric choke for an old 1800 RPM generator. Maybe a musical fan control. These are slow and harmless and right in the sweet spot for a ten dollar board with no OS.
Yes we do not live in that world anymore … nor are we in the world where things like basic USB hid, midi and multiple serial streams are all that important … those are 30-50 year old solved problems
I read this as “Here’s a long list of reasons why MicroPython is great. But C/C++ is better because I say so”.
Really, no. Micropython has an (effectively) integrated async bluetooth LE implementation. It would take for-ever to write this in C, but the whole of my firmware is a hundred lines of Python and runs on an RP2040.
The more I use Python, the more I dislike the language and the less sense this project makes.
I mean, what is the actual problem that this tries to solve?
It gives people like myself the ability to use microcontrollers on a whim. Sure I could do something with an Arduino or a PIC or whatever else, but something about the code/flash/test cycle is just enough to discourage me from all but the most motivated projects. The cool ideas and what-ifs? They never happen, it just feels like too much work. Heck if I know why. Brains are weird.
But being able to open a live python interpreter right on the device and test things in real-time, and then just copy the files with my code to the device? That works so much better for me.
It’s not for everybody. And that’s fine. The world would be pretty boring if we were all the same.
I’m exactly the opposite. High le el languages on MCUs seem to offer expedience and to accelerate the development cycle… until you end up just repeatedly banging into the limitations of the language. Either you find bugs in the implementation, or run out of memory, or its too slow, or it just plain lacks the capabilities you need…. you end up spending MORE time fighting with the environment and implementation than you would have if you’d just dine it the right way from the start. Or you get frustrated with the whole project and rage quit
One good thing with MicroPython is that one can easily mix and match it with C. And there are other good features for writing efficient code, like the native and viper code emitters, as well as an Assembler for ARM Cortex M that is accessible via Python.
“I mean, what is the actual problem that this tries to solve?”
You can argue barrier to entry/development speed, but it’s also a scripting language for microcontrollers, which means you can *massively* extend what the microcontroller’s capable of. Instead of having 20 different sketches you upload, you store all 20 different scripts on a cheapo SPI flash or an SD card.
There are many but the primary one our customers appreciate is a 20-30% reduction in software development costs.
^ this, being able to develop complex stuff in a fraction of the time is often worth it even if the end hardware costs a little more or is slightly less efficient than a “perfect” solution that takes 5-10x the time to develop.
Algorithms plus data structures = programs. Primitive languages like C get in the way.
I agree that Python can have its warts. But as a relatively high-level language, it fits in my brain *much* better than C or C++ ever has. I also have the advantage of coming to MicroPython with lots of work experience in plain ol’ Python — so this speeds up development immensely for me.
I absolutely respect someone not liking Python, or not feeling its the right tool for the job they have. But I’m a hobbyist, so I’m doing this for fun — and for me, programming in Python is much easier, and *much* more fun, than C/C++.
Toil.
Implementing MQTT with an inextricable private key stored on a secure Element peripheral, 10x I2C sensors, a display, OTA updates, CAN, Ethernet, etc. over a few days vs. a few quarters.
Love MicroPython :-) Now I also run it on RP2040.
This reminds me: I’ve started seeing FPGAs on a board with 2280 m.2 interface. I’ve also seen USB / thunderbolt docks, with the option to add an m.2 SSD.
Video out, Ethernet, Keyboard, Mouse, USB key – heck, those docks even have power in.
Hmm. Do you even need a laptop? Or could you get by with a Micropython prompt, running off a microcontroller in the dock?
I used to design Thunderbolt devices, such as docks. Think of Thunderbolt as VPN for PCIe and video data. It allows you to easily hang video and/or PCIe devices off the end of a little copper cable or a longer optical cable and tunnel data to and from them, but they’re using standard PCIe I/O chips which could just as easily be on a motherboard. You still need a PCIe equipped CPU to make them do something not to mention Thunderbolt controller drivers. Microcontrollers generally don’t have PCIe; that’s a CPU thing, and Intel holds a complete lock on the Thunderbolt controllers as well so don’t expect to find any detailed information on how they function. Video still comes from the motherboard too, it’s just delivered via a VPN of sorts between the host CPU and the remote video output port. The dock does not contain video memory, video timing generators, etc.
m.2 uses either SATA or PCIe. In a Thunderbolt to PCIe m.2 dock you only need the Thunderbolt controller since it outputs PCIe. In a Thunderbolt to SATA m.2 dock you need to add a PCIe to SATA controller like the ASMedia ASM1062 to name one dinosaur example. If you want Ethernet you just add a PCIe to Ethernet controller but there are more integrated options too if you only wanted Ethernet.