This is what Arduino and Arduino IDE did for millions of hobbyist, but it is time to ditch C/C++ for MicroPython.
In this  PyCon talk by Matt Trentini, a demo of QR code generation proves that with plain C and with MicroPython bindings, the performance is identical - 11.5ms. MicroPython is slow, and if the QR code library was written in pure MicroPython, it would take 1500ms. Therefore, it is critical to put performance demanding code in C/C++ modules and compile a MicroPython bindings.
I think this is one of the best things that's happened to embedded development in a long time. Lua is nice but IMO Python is even better :)
There is also Async IO library support for MicroPython. So ISRs can trigger coroutines!
Still quite a lot of work left for pdb-like features but I'm optimistic it'll get there!
(who named these interesting commands?)
> One of the earliest references to these commands in BASIC, if not the earliest, is in Altair BASIC.
So, it seems to date back to 1975.
We should make Rust compile to Arduino and other embedded devices and be done with it.
Write your low-level/high performance code in whatever. Then write top-level logic-- and let your users script in-- micropython.
I'm teaching a middle school class this year with micropython on embedded. I can't fit Rust in with everything else I'm teaching in one trimester. I've even written an IDE which runs in the browser (on chromebook, etc) so there's no external dependencies for them.
upip install foo
My brother taught a robotics team where he used https://www.adafruit.com/product/3333 and was really happy with it... but I wanted something a little beefier and to have wireless options.
It's still significantly faster than developing wholly in C - or Rust for that matter. And that's if writing in a low level language is required at all.
 - https://github.com/dcmorton/esp32-micropython-image-builder
This was one of the reasons CircuitPython was forked from MicroPython. Adafruit wanted consistency across all the platforms they sold and one of the features they insisted on was the USB drive support to make it easier for the educational market they cater to.
How hard is to write bindings for micropython?
I've looked into cython but I'm not sure it's what I really need.
This might help: https://github.com/stinos/micropython-wrap
EDIT: actually neither FFI or this wrapper you linked are what I need. I need to execute micropython from C++, not the other way around.
But aren't these contradictory -
>but it is time to ditch C/C++ for MicroPython.
>Therefore, it is critical to put performance demanding code in C/C++ modules and compile a MicroPython bindings
I understand that these are underlying issues of Python itself and I've been burned before because of it. Had a massive python project in my previous startup, it became very clear soon enough when the user base grew that only way to extract meaningful performance(and to bring down server costs) was to replace core components with C-extensions(e.g. Concurrency, Networking). Although we were able to do it, it is a huge overhead for a small startup and capital intensive.
If I have to recommend Python to someone who is new to programming, I have to add a disclaimer that "If you want to build something which demands serious performance with it, you'll also have to learn C/C++"
All those can be avoided, if we could just take up a language which was specifically built to fix the underlying issues with Python i.e. If it's the utility we want, then Go.
As far as embedded is concerned, TinyGo does what MicroPython does. But I've found solace with Gobot via Firmata, although it demands Client-Server architecture the utility of not having to flash the Microcontroller each time we make a change is worth it, besides having all the libraries we have in the Go ecosystem at our disposal. I would recommend this for home projects where Client-Server arch is not an issue, I recently built a 'Butt Triggered Pomodoro Timer' with it.
Most projects are integrating parts into a whole. While expert programmers might be needed to create the parts & package them as libraries, how often is the same true of larger assemblies of parts that solve a domain problem?
Blueprints in Unreal Engine are an interesting case study. Programmers create components in C++ and expose APIs for them. Level designers use Blueprints to integrate & orchestrate those components into levels, without the same need for programming expertise.
Anything scalable can make use of performance improvements, so that means production applications with hundreds and thousands of concurrent users is a right example in my experience. Apart from better usability, performance enhancements results directly in greater capital-efficiency(server costs).
My subjective opinion is, the only place I wouldn't consider using Go is when it's garbage collection could hypothetically be harmful(literally) i.e. Say I'm coding a system for a ventilator, I will either go with traditional/proven language for that environment like C or a newer, safer alternative like Rust.
How beautiful would that be; an awesome package manager (Cargo), strong types, blazing fast bare metal performance, safe memory and less strange errors that are hard to debug in an embedded system!
also 2014 https://news.ycombinator.com/item?id=6996692
Many submissions but those seem to be the interesting threads.
Is there any support for embedding it within an application, i.e. as a replacement for Lua? Or is there another lightweight Python implementation (or Python-like language) that supports this?
I bundled the official Python (CPython 2.7, that was some years ago; but I don't think CPython 3 would be so much different) in an application (http://albertz.github.io/music-player/), and the whole MacOSX app zip file ended up at 11 MB. This includes my whole app + whole CPython 2.7 (including all stdlib) + extra Python libs (all the ObjC/Cocoa bindings, which I use for the GUI). I find this is still pretty ok.
(Still much smaller than Qt, wxWidgets, Electron, or whatever else there is. But maybe this comparison is unfair.)
The scripts to build CPython suitable for embedding it into an app are here: https://github.com/albertz/python-embedded/ (But this is not really updated, and so far for CPython 2.7, not CPython 3. But this is not really so difficult anyway. These scripts are mostly such that you have it as a Xcode project and also compiles on iOS.)
I think Dropbox does the same, as far as I remember.
But so is MicroPython. We were looking for a higher lever than C language for an embedded Linux system* and one engineer was massively in favor of MicroPython. But it’s not python, it’s based on 3.4 so it’s like python but not. It has its own rules and particularities. When I hire a new engineer I’d rather say “here read this book and learn this language” than “ok we have this python work alike/fork, now learn all these exceptions.”
It’s also not a good fit for embedded Linux system programming like Lua is.
*) this is an in production, professional environment, which decision will have years of legacy support and ramifications.
Many applications in the graphics space embed or otherwise allow Python scripting. Some open source examples are: Blender, FreeCAD, GIMP, Inkscape.
The crowd of people who speak Lua is pretty different than those who speak Python.
I would guess the Lua crowd to be older, more experienced, but smaller.
The Python crowd is much bigger, and includes people who dabble in coding rather than those of us who do it for a living.
It depends on the user base of your application, but I can totally see why Python would be a better embedding language for users to use. You build the product for the users after all.
I'd also like a language that puts more emphasis on backwards-compatibility than Lua. Sure, everyone complains about the Python 2 => 3 transition, but there have been 3 new major versions of Lua since the release of Python 3.
The only other implementation that really supports it is PyPy which is not in any sense more lightweight.
While MicroPython was designed to be "bare iron", it wasn't overly difficult to port it to run as a separate task inside the XBee firmware, and connect it up with internals for I/O and file system access. These are ARM Cortex products with firmware sizes in the area of 500KB to 700KB.
But, my impression is that Snek is mostly for "learning" while MicroPython is intended to do "real work" (obviously those are not disjoint categories).
What is a “few kb”? Because last I looked Micropython was like 256kB and the smallest JS interpreter that had foreign function interface was 53kB.
From the manual:
> […] could fit on our existing Arduino Duemilanove compatible hardware. This machine has:
> 32kB of Flash
> 2kB of RAM
However, I did it with an ESP8266 running MicroPython; I was impressed that such a small, cheap little computer was able to connect to the internet, retrieve XML, parse it (this step in particular), and update the state of each of the WS8211 lights with ease, all with some quick, easy-to-write Python.
However, one should not be disillusioned — I doubt this can be used to deploy a mass market product.
However, I can see micro-python’s value in rapid-prototyping to some extent for someone who is not into embedded/firmware as much.
My rationale for saying this is that in addition to programming in any language, you need to understand hardware, including safety. And I think that by the time a person reaches that level of knowledge, they have probably familiarized themselves with programming at a variety of levels from bare-metal C up to desktop software.
Now, I've only been playing with MicroPython (actually the CircuitPython fork) for a few months, and at this point haven't come up with a "scale" of project that needs more than bare metal C but less than a full blown operating system. But then again I haven't come up with any good product ideas in that time period.
As I mentioned to a friend of mine: "Hi, we're programmers, and we're here to burn your house down."
Between the two real projects that I'm nursing along right now, one uses a FFT and the other an interrupt running at 170 kHz, so neither of those can be pure Python projects yet.
Neither of those rule out using MicroPython. Though you are likely to have to do some C work to achieve higher performance.
>>>Compiling the cmodule into MicroPython
>>>To build such a module, compile MicroPython (see getting started) with an extra make flag named USER_C_MODULES set to the directory containing all modules you want included (not to the module itself). For example: ...
This is not precisely for the faint of heart, but should not be prohibitive for a seasoned embedded developer. ;-)
Even if you are careful about manual allocation, Python is not a compiled language, and the interpreter will frequently request heap allocations on its own. So if you expect a program to run for a long time without crashing, you'll probably need to use much less memory than the system has available.
It's also quite slow. That's not a huge issue since modern microcontrollers are fast and you can write your own .mpy modules in C, but it does affect power consumption.
It's also pretty high on the "drama" scale as far as OSS projects go. Last I checked, there was a brewing split between the original maintainer and one of the largest contributors, and Adafruit have already gotten frustrated enough to make a hard fork called CircuitPython.
Personally, I would use it a lot more if I could trust it to run stably. For reference, I've used it in a Cortex-M0 clock which can run more or less indefinitely, but needs 16-32KB of RAM just to read an I2C clock and set some 7-segments. And when I tried to set up a simple wireless MQTT sensor with a supported Cortex-M4 board, I couldn't get it to run longer than a few days before the application crashed from memory fragmentation.
So from my perspective, it is only usable for trivial tasks, and even if it were more stable, I'm not sure which fork would be the right choice for long-term development.
Still, it's an excellent educational tool and I always like to see more of those.
I just can’t fathom deploying a full product where I don’t have this sort of control?
From a performance/space standpoint there is decades of compiler optimization experience with IAR/GCC, I’m not sure micropython can achieve that.
I guess I’m speaking from the standpoint of a firmware engineer, I honestly don’t think going with micro-python for our next product will buy us anything.
However, as I said; if you’re not into firmware and/or just getting started, this makes a great prototyping language.
(And hopefully get sucked into firmware(I wish we had more firmware-engineers ;-) ))
If it was good enough to run Turbo Basic, Quick Basic, Turbo Pascal, Turbo C++, Clipper, it can easily take MicroPython.
I backed it way back when, I think for the ESP8266 support, and have loved it ever since.
> Like Python, Snek doesn’t have an explicit Boolean type.
So yes, it's not possible to use very small devices. Still, this means that MicroPython can run on reasonably small, reasonably cheap devices - and your development effort can be significantly reduced.
I never thought it would be that easy, but it converted the task of writing something that does MDIO, SPI, and WiFi (with a webserver) in C, to basically a day of work.
Also the "feel" of running an interactive python shell on a tiny 1x3cm board as part of the initial bring-up process after manufacturing is just awesome. Controlling every IO "manually" via the interactive shell is so much better than seeing your prepared C code crash and burn, and only then start debugging it.
You can buy one of their boards with the BSP but that's over $40, yikes.
To use micropython you need at least an M4 class micro-controller so that a $5 or greater part.
Or you could just stick with C and use a M0 class micro that costs < $1.
A difference of $40 in BOM cost makes it only applicable to the hobbyist. Which is fine, but its just a toy.
Is it as fast as C? No. Does that mean it's useless? No.
The absolute coolest thing is to take a $2 Wemos D1 clone, put micropython on it, hook it to a sensor (I've been using temp and humidity sensors lately) and have it periodically fetch "http://webserver-ip/temp?t=<value>&p=<value>" every 10 seconds and have a little python webserver sitting on an machine on your network that is stuffing the values into influx or some other DB.
This is trivial to do, and takes little to no embedded coding experience on the ESP8266. That's a win as far as I am concerned.
 - https://github.com/dcmorton/esp32-dht22-upython
But it definitely does have issues with memory usage. Personally, I hope that it will become more viable as its development continues and RAM densities increase. I love the syntax and ease-of-use, but I don't love needing a $10 chip for a $1 task. Hopefully it'll be usable for non-trivial tasks on a $1 Cortex-M23 chip in a few years.
It also really shines in educational environments. I see a lot of promise in the progression from MakeCode (primary school) to MicroPython (middle/high school) to programming "real computers" (high school/college). It's a natural progression, and understanding simple microcontrollers takes a lot of the scary "magic" out of learning about complex application processors. See, for example, the BBC micro:bit (which also has a MicroPython BSP).
ArduPy is a combination of Arduino and MicroPython. MicroPython uses the universal Arduino API to control the hardware so that it can be compatible with new platforms quickly. With the help of the aip package manager we provided, you can transform your favorite Arduino library into a MicroPython library.
It works very well on the Seeeduino XIAO (https://www.seeedstudio.com/Seeeduino-XIAO-Arduino-Microcont...) which is arduino compatible and costs $4,90 per piece. You can even get a grove shield for the same price and you are ready to go.
Python 3.4 is now over 6 years old. Are there plans to add features from newer Python releases? Or perhaps the developers feel that Python's newer features wouldn't "pull their weight"?
Generally MicroPython can absorb modern Python features where the implementation can be shown to be efficient, particularly with low RAM costs.
I'm loving the thought of being able to customize my keyboard's functions by just dropping python files onto its USB drive. Looking forward to using this on my Dactyl-CC build.
What boards work with MicroPython? On their website, they only list their own?
I know that previous me was very scornful of micropython (the original boards were pretty expensive and power hungry)
However, the ESP* and SAM21 microprocessors have changed my opinion. Yes python is still wasteful. but I can now operate in the microamps, and for less than £7
Not only that, these micro controllers has a wealth of documentation and addons.
I feel like I've discovered the arduino all over again.
The original pyboard can be had for around $20 and used to be closer to $30. The ESP8266 is a couple dollars, and the ESP32 is just north of $5.
Obviously, we're only talking about a handful of dollars, but for embedded systems, it matters.
Single global thread issue still around?
And whilst I like ulisp it is tie down with arduino and hope this will go out. Trying the js microprocessor implementation and let these two compete at least.
If I got out a microscope and looked at cross sections of a pyboard, could an expert point out the sections of physical gates and other parts that implement each python bytecode?
MicroPython differences from CPython