MicroPython | Hacker News Reader

MicroPython

micropython.org

338 pointsneilpanchal147 comments

MicroPython is stellar. If you're building an embedded system for people to hack and customize, make the highest level abstraction of the embedded system in MicroPython so that users can easily modify/patch/contribute/hack your system with ease.

This is what Arduino and Arduino IDE did for millions of hobbyist, but it is time to ditch C/C++ for MicroPython.

In this [1] 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!

[1] https://www.youtube.com/watch?v=437CZBnK8vI

Great so now in order to create a performant embedded app i need to write everything in two languages.

We should make Rust compile to Arduino and other embedded devices and be done with it.

It already does! (As long as the target supports LLVM)

https://rust-embedded.github.io/book/

There's a real advantage to having an interpreter.

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.

Exactly. All high level logic (no loops, massive arrays, and heavy arithmetic) can be written in Python. Overhead for C binding calls is minimal. The downsides related to undetectable slowless exceeds the utility and ease of development. Not to mention, over the air `upip` installs! If you have an ESP32/8266 or any wifi enabled chip, you can call:

  upip install foo

at runtime!

Which boards are you using and how did you chose them?

I designed a little board that shims under a standard ESP32 module and has capacitive touch, a couple channels of motor driving, MEMs gyros, and LEDs. I was able to get things to $5/unit at qty 50 (counting ESP32) this way and to get exactly what I needed.

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.

Generally the tactic is to write everything in MicroPython and, only if performance requires it, drop into C to write small sections.

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.

TinyGo (https://github.com/tinygo-org/tinygo) is the Golang equivalent of this for anyone who wants a more performant (than python) and simple language to use.

Similarly there’s mruby which is quite stripped down, not sure of the exact requirements though (those micropython requirements are quite impressive)

https://mruby.org/

But no REPL for real-time probing or testing, so you’re in a big-guess-recompile-deploy cycle, correct?

Do you think it's suitable as a game scripting language?

How hard is to write bindings for micropython?

I've looked into cython but I'm not sure it's what I really need.

It is not too difficult, just extremely verbose (even for a simple int arg function): https://docs.micropython.org/en/latest/develop/cmodules.html

This might help: https://github.com/stinos/micropython-wrap

thanks, this is nice but building it seems complex. FFI seems more suitable.

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.

I would go with uLisp because Lisp for me [1]. And for IOT and small distributed things Nerves [2]. I started with Basic Stamp in 1997 way before Arduinos were born, and I then went on to PIC chips with C and asm.

[1] http://www.ulisp.com/

[2] https://www.nerves-project.org/

The one big issue I've had with MicroPython is that it's a PITA to manage files on it. I use this hacky tool called "ampy" to do it, and wish that the device could just be mounted as a media device. CircuitPython, however, does accomplish this, with the microcontroller showing up just like a USB drive.

I like this feature of Circuit Python too. An issue is that some boards don't have the USB hardware needed to make this work.

Very soon you'll be able to mount a PC filesystem to appear on the device, so just make changes locally and they're reflected on the device. It's an exceptionally productive way to develop - I even prefer it to working with USB mass storage.

Bit of shameless plug, but I put this [0] together to make it easy to build a simple, flashable MicroPython image with your code included.

[0] - https://github.com/dcmorton/esp32-micropython-image-builder

Some Python IDEs like Thonny and PyCharm can seamlessly do file transfers for you over serial. Thonny has actually been a great tool for that on ESP boards.

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.

I haven’t looked at the latest advancements with MicroPython, but last I checked it was both slow and unsafe in ways I wasn’t used to, such as certain language features not being allowed in interrupt handlers, certain operations being interruptible, etc. I totally hear what you are saying about building stuff for less technical people to hack on, but as someone comfortable with C (gasp! shock!), I prefer the predictability I know. And I normally write Python code for nearly everything.

Not really following the logic wrt predictability. I mean, you run it on a microcontroller so yes things can be interrupted. Just like in C. And while allocation not being allowed in an interrupt handler can be annoying, it's also predictable once you know it. And no matter what language you use, you don't go wild in an interrupt handler on a microcontroller anyway.

IIRC things like accessing or assigning dict values were not atomic and could be interrupted. Sure you could code up the same kind of pattern in C but you could also code up a lot of patterns that don’t have this problem.

Hey, that's me - if anyone has questions about that then you can ama!

The biggest thing you are underselling (if at all), is that you can have a repl directly into the device itself and doing lots of exploratory programming directly in-circuit.

This jumps it to the top of my list of tech to explore on microcontrollers.

Yes, this is a complete game-changer; I love showing experienced embedded engineers how to connect to the REPL, and poke live, interactive I2C or SPI at a peripheral. :)

I only wish Micropython had a real debugger (pdb).

#5026 was merged last year; it provides the sys.settrace primitive which paves the way for debugging support.

https://github.com/micropython/micropython/pull/5026

Still quite a lot of work left for pdb-like features but I'm optimistic it'll get there!

PEEK

POKE

(who named these interesting commands?)

Via https://en.wikipedia.org/wiki/PEEK_and_POKE:

> One of the earliest references to these commands in BASIC, if not the earliest, is in Altair BASIC[4].

[4] https://archive.org/stream/bitsavers_mitsMITSAl_6669937/MITS...

So, it seems to date back to 1975.

I'd love to try it out but the realm in which I am moving is around 32K of flash and 6K RAM. And if my research was not wrong MicroPython needs at least 256K flash and 32K RAM, and that's without any user program in Python on top of that. That's quite a lot ...

That's roughly true: 32KB RAM and 256KB Flash will provide a decent MicroPython environment. I'm afraid if you have fewer resources than that you should probably look at other alternatives.

I understand what value MicroPython holds for Python community who want to get into embedded computing.

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[1].

[1]https://abishekmuthian.com/butt-pomodoro-a-butt-triggered-po...

Thanks for the insight, in your experience how has the performance been?

With Go? It's magnitude faster than python and it's concurrency might be paralleled maybe only by elixir although I wonder whether the later would match Go's utility based programming paradigm which results in faster roll-outs.

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.

What are you finding the Go environment takes for resources on your micro before your actual code?

I wonder how many projects really need the performance?

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.

>I wonder how many projects really need the performance?

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).

I don't want even less types in my code though; I don't want Python on Arduino, I want Rust: https://github.com/avr-rust/ruduino

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!

If curious see also

2014 https://news.ycombinator.com/item?id=7840566

also 2014 https://news.ycombinator.com/item?id=6996692

2015 https://news.ycombinator.com/item?id=9558969

2016 https://news.ycombinator.com/item?id=11181158

Many submissions but those seem to be the interesting threads.

There was also the submission about Pycopy recently, a fork of MicroPython: https://news.ycombinator.com/item?id=23446721

MicroPython seems to be heavily focused on embedded systems.

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?

It's slightly more constrained for performance but maybe Starlark is what you're looking for? https://github.com/bazelbuild/starlark

It should be supported, although I don't have any good examples of people doing it. There is work being put into making micropython into a powerful webasm package for frontend development.

https://github.com/micropython/micropython/tree/master/examp...

Why not just use Lua? :) yes I get it, Lua is yet another language to your stack.

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.

“Not quite python” is a subtle point many people miss and indeed can be an issue. Third party library support is also huge, does micropython support the cpython library ecosystem? In this case the plethora of lua libraries readily available via luarocks is a huge advantage.

Why would you want to replace Lua in this space? At least why replace with another dynamically typed, imperative scripting language, but without tail-call optimization? What would be the gain?

I was wondering the same as the parent, and in my case it's library support (e.g. NumPy) and compatibility/familiarity in the space (VFX) where Python is everywhere and Lua is unheard of.

If you want NumPy support in particular you basically have to use CPython.

The only other implementation that really supports it is PyPy which is not in any sense more lightweight.

Although much smaller in scope than NumPy, MicroPython (and CircuitPython) now have the ulab library which provides similar fast array manipulations:

https://github.com/v923z/micropython-ulab

So, use Python instead of MicroPython.

> Why would you want to replace Lua in this space?

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.

In todays world, I'd make some V8 bindings and get users to use javascript, because that's even easier to embed, has a bigger ecosystem via nodejs/npm, and has a probably larger userbase... It's got a nice remote debugger/UI too, which is quite a plus if you're expecting inexperienced users to write plugins/modules for you.

The Lua crowd includes kids learning to code because they want mods in Minecraft and other games. Sometimes I see Lua suggested a a first language over JavaScript because it's much smaller and has less warts (plenty of warts exist though). Can you even use V8/SpiderMonkey in the same way as LuaJIT?

You mean Minetest, right? Minecraft doesn't have native modding support, let alone Lua modding support.

Various, including some very popular, mods for Minecraft include Lua. I assume that's what they are referring to.

I'd prefer to use a language that's more orthodox than Lua, e.g. one with class-based OOP and separate lists & maps, rather than tables-for-everything.

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.

Lua versioning is a really weird thing I'll give you that. I find class-based OOP a point against a language rather than for it, but there's already a huge chunk of languages that compile to/add types to Lua (https://github.com/hengestone/Lua-languages), with Wu and Amulet looking intriguing to me.

What is lightweight for you?

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.

Wow. Very interesting. Hope it can be upgraded to 3

If it is a desktop-type application, just use CPython itself? It has good embedding support since forever, and is the "Python" that most people know and are used to. Best compatibility with existing code, for third party libraries and tooling. https://docs.python.org/3/extending/embedding.html

Many applications in the graphics space embed or otherwise allow Python scripting. Some open source examples are: Blender, FreeCAD, GIMP, Inkscape.

There used to be Jython, for embedding inside JVM apps, but the 2/3 transition killed it.

Digi International embedded it into some of their XBee wireless radios (802.15.4-based and Cellular models) to allow customers to run an on-device application without compromising any certifications for the radio portion of the firmware. Easier than needing to design hardware with an additional host processor and work out the serial communications between that host and the radio module.

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.

Yes, and this has recently attracted some focus. Take a look at the example for embedding MicroPython:

https://github.com/micropython/micropython/tree/master/examp...

We've been running it like that for multiple desktop applications for years. So it's supported in the sense that it works but depending on what you do with it exactly it needs some boilerplate code which mostly means copy-pasting some parts from one of the main.c files for the different ports, no big deal. Creating bindings is another point which requires boilerplate code but that's no diferent from other scripting embeddings.

There also exists a Python-like language for when you only have a few kb of memory, and can’t even run MicroPython. It’s called “Snek”:

https://sneklang.org/

There was a good LWN article about Snek a while ago: https://lwn.net/Articles/810201/

But, my impression is that Snek is mostly for "learning" while MicroPython is intended to do "real work" (obviously those are not disjoint categories).

That’s cool. Hadn’t seen that one.

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.

> What is a “few kb”?

From the manual:

> […] could fit on our existing Arduino Duemilanove compatible hardware. This machine has:

> 32kB of Flash

> 2kB of RAM

[…]

MaixPy ported Micropython to K210 (a 64-bit dual-core RISC-V CPU with hardware FPU, FFT, sha256 and convolution accelerator). It includes a general-purpose neural network processor, which can do convolutional neural network calculation at low power consumption, for example obtain the size, coordinates and types of detected objects or detect and classify faces and objects. It can load TensorFlow Light Neural Nets.

https://maixpy.sipeed.com/en/

That is awesome! Unfortunately the K210 link on the site is giving me a certificate error so I'm a bit afraid clicking into it. Do you know if the library will work with (https://www.seeedstudio.com/Sipeed-Maix-Cube-p-4553.html)?

I think it should. I have the Maix-Go (https://www.seeedstudio.com/Sipeed-MAix-GO-Suit-for-RISC-V-A...) and it works pretty well. I also own the m5stick-v which has the K210 builtin (https://m5stack.com/collections/m5-core/products/stickv). I connect to them via screen on linux and get a micropython prompt in an xterm and can use it interactively. There is also an IDE available. See also the docs at M5Stack: (https://docs.m5stack.com/#/en/quick_start/m5stickv/m5stickv_...)

It does; in fact with my Maix Cube it came shipped with it pre-loaded.

I'm literally at lunch on the way home from picking up a delivery of one of these.

I once built a METAR light map like this - https://slingtsi.rueker.com/making-a-led-powered-metar-map-f...

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.

I have an ESP8266 wired into my intercom buzzer for opening the door remotely[0]. It has been unreasonably stable and reliable. Many months, possibly into years, of consecutive uptime. I used the arduino IDE and modified demo code for a web server. The cheapo dev board had it's blue LED die (mercifully) but is still chugging along. It's crazy what these things can do.

[0] https://jeremypoole.ca/posts/put-your-door-on-the-internet/

I think this is good for someone getting started with microcontrollers(similar to the Arduino)

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.

Why not? I've used it and it works fine, you don't get the granular control you get with C but I don't think there's anything that makes it fundamentally unsuitable for production.

When you have a product that is running out of flash and you want to deploy an update for your customers, you need that granular control.

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 don't think it's inconceivable that there would be a product where you'd have ample storage and CPU power for your application and would want to optimize for speed of development instead. I've built things on MicroPython that would be just fine to ship as they were, for example, if I were to commercialize them.

When engineers start cutting corners and start to design not for performance but “speed of development” — it becomes a slippery slope.

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.

If you're a firmware engineer and already familiar with the ins and outs of C, I don't think it buys you anything, agreed. I also don't think there's something fundamentally wrong with it that would force a hobbyist to rewrite everything in C if they wanted to commercialize their prototype.

I can agree with this. If you find a language that is more approachable and gets stuff done, you should go for it.

(And hopefully get sucked into firmware(I wish we had more firmware-engineers ;-) ))

For me, some of the hardware supported by MicroPython is more powerful that what I had on a desk during my MS-DOS days, so I can easily see using it for certain kinds of applications.

If it was good enough to run Turbo Basic, Quick Basic, Turbo Pascal, Turbo C++, Clipper, it can easily take MicroPython.

you're being a little hyperbolic. haven't you ever heard of premature optimization?

There are a few reasons. Number one, stability issues from heap fragmentation.

http://docs.micropython.org/en/latest/reference/constrained....

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.

Adafruit's fork was for business reasons as they wanted control over implementation for the hardware they sell, and to focus development efforts on making it more accessible to newcomers. While I'm not thrilled with the fork since it dilutes the original project imo, they do still contribute back to the micropython project. But I don't think there's any lost love there, they just had different goals with a financial stake (unlike the uasyncio split which was ego driven)

I have an ESP8266 running MQTT to make an alert on a speaker (I2C) on demand. I just looked at the counter I periodically send to MQTT. It has been up for over 200 days. It does not leak.

Digi started using it as the user facing API for the programmable version of there xbee radio modules and those are very popular.

In my view, nothing can be used to deploy a product, without further consideration.

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.

> one uses a FFT and the other an interrupt running at 170 kHz

Neither of those rule out using MicroPython. Though you are likely to have to do some C work to achieve higher performance.

Yes, definitely. Any application that I can think of off the top of my head involves adding C code. This is not a hurdle, but would be for someone who is using Python to get into embedded programming at a beginner level. From the MicroPython documentation:

>>>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. ;-)

You might be interested in ulab for FFT and other numpy-ish things: https://micropython-ulab.readthedocs.io/en/latest/ulab.html#...

Everyone is open to their opinion; in the meantime the company I work for uses it for mass market devices in the medical domain. ;)

MicroPython is amazing, it runs on very tiny microcontrollers not much else runs on, and makes development of hobbyist embedded projects orders of magnitude easier than C.

I backed it way back when, I think for the ESP8266 support, and have loved it ever since.

I wouldn't say "very tiny". For example, does it run (and can do something useful) on a 8 KB cortex M0 with 24 KB of flash?

For that, maybe snek[1] would be more suited.

[1] https://sneklang.org/

Snek's documentation has errors.

> Like Python, Snek doesn’t have an explicit Boolean type.

No, an effective MicroPython environment requires 32KB RAM and a couple of hundred KB of flash (it's possible to use less but the compromises are not worth it IMO).

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.

Does anyone have any experience beyond short programs/sketches with micropython? The most I've used it for is playing around with a microbit. How does it hold up?

I’ve got esp32s running a simple API over wifi to control a strip of addressable LEDs, with scheduling and some other functionality. Had some interesting problems to solve along the way but it is a fun language to work with and micropython is very stable on esp32.

I've been trying to make a (toy) contact-tracing system on microbits with micropython, but keep hitting RAM and flash limits; the lack of being able to write in append mode severely limits it's usefulness as an offline datalogger

Had it manage an Ethernet Phy IC via an MDIO interface, and an FPGA over SPI. The MDIO was bit-banged from micropython, and SPI is a built in feature. This was running on an ESP32 creating a WiFi to Gigabit Fiber bridge (obviously not at gigabit speeds).

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.

Neat, but not very practical. To be of any use you still need board support to drive the I2C, SPI, etc which means you have to use C anyhow.

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.

It runs very well on ESP32.

I've done work for a couple of clients, converting a micropython implementation to C on and ESP32, that would disagree with that statement.

If they need you for that they probably would not have been able to write it themselves in C in the first place?

The ESP32 port still has a few rough edges, particularly around peripheral control. But it's a popular device and the port is improving all the time.

To be fair, there are BSPs for cheap chips like Espressif microcontrollers and a myriad of minimal development boards. You don't need to buy a pyboard, and part of the reason those are so expensive is because they help fund the project's continued development.

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).

On the boards it has been ported to, I2C and SPI are directly supported (https://docs.micropython.org/en/latest/library/machine.SPI.h...). No C coding necessary. It's not a replacement for C on every embedded application, but for prototyping and one-off applications it's hard to beat the productivity gains. It will run on an ESP8266-01 module for as low as $2 ea.

Going to disagree here, i2c and spi work fine in micropython.

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.

Not only that, but you can live code in the repl on the same device. One can solve a physical problem in less than 15 minutes using these devices.

I've done something pretty similar that with my project here [0]. Instead of using MQTT the ESP32 feeds directly to an InfluxDB database.

[0] - https://github.com/dcmorton/esp32-dht22-upython

Huh? I use MicroPython on ESP8266's that I'm sure are way under $5 in bulk these days. Including I2C support and various other stuff, without writing any C. I am a hobbyist but I don't see any reason why the same thing wouldn't work in a commercial product.

Look into ArduPy, which lets you compile arduino libs as loadable python modules:

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.

https://github.com/Seeed-Studio/ArduPy

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.

> MicroPython implements the entire Python 3.4 syntax

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"?

I'd be interested in knowing how much bigger Python has gotten since 3.4 time frame. If course it's not unthinkable that it could always get smaller if there's a lot of refactoring going on, but that might be wishful thinking.

Resource usage is carefully considered when introducing new features; but there are cases where it has becomes smaller. The recent addition of LittleFS meant that a couple of KB more RAM was available at boot for example.

Python 3.4 is actually the baseline for MicroPython these days. Many other more modern features have crept in; such as f-string support that was recently added. And the asyncio support is a modern implementation too...

Generally MicroPython can absorb modern Python features where the implementation can be shown to be efficient, particularly with low RAM costs.

In my experience, one should understand the c dependencies to use micro/circuit python for most of desired uses. Still great stuff. The mere decrease in linecount for simple algs has real value.

For plumbing stuff together it's probably great. Anything lower level that requires performance or real time constraints will probably not do.

Micropython can do some real-time stuff. It's limited, but a bit easier in my experience than getting a Preempt-RT running on a Raspberry Pi.

The coolest application of Python on uCs that I've seen recently is in the custom mechanical keyboard space:

https://github.com/makerdiary/python-keyboard

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.

Check out uiflow from M5Stack. It is a web-IDE which uses micropython for ESP32. You can use the M5stack grove sensors. The IDE generates python code which can be used on any MicroPython Implementation (ESP8266, EPS32, Raspi, CircuitPython, Micro:Bit, you name it) and the python libs are all open source.

https://flow.m5stack.com/

I'm more familiar with CircuitPython because I've bought a few boards that could run it, though I've stuck with Arduino so far. It seems to be a fork started by AdaFruit, but it looks like there are other vendor boards it works on like SparkFun, Teensy, and Arduino.

What boards work with MicroPython? On their website, they only list their own?

You have to find the version of MicroPython that has specifically been ported to your board. In addition to the PyBoard (STM32), there is ESP8266, ESP32, BBC Micro Bit (ARM Cortex-M0), and WiPy (CC3200)

Remarkably, it has recently gained (still not mainlined) 68000 support: https://twitter.com/micko_mame/status/1256221039308267520

I've done quite a few firmware development projects (they're commercial type and deployed in fitness industry, police vehicles, etc). They type of thing they do, I have a hard time imagining doing it in Python.

For rapid GUI application prototyping LVGL has micropython bindings: https://github.com/lvgl/lv_micropython .

I've been doing microprocessor stuff since the basic stamp 2 came out. (not that I'm an expert, I've just been fiddling over a long amount of time)

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.

LEGO ist using it for SPIKE Prime and their related upcoming 51515 robotics set. There is even an inofficial firmware for their regular Powered UP electronics enabling MicroPython.

They really push the pyboard which is cool and all, but imho, the killer application for Micropython has been the ESP8266 port and now the ESP32.

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.

Seeedstudio provides ArduPy for their Wio Terminal which can generate micropython libs from Arduino C Libs. So you can script Arduino Code with micropython on the device. As IDE they provide plugins for MS VisualStudo Code.

https://wiki.seeedstudio.com/ArduPy/

Another great resource for micropython tutorials is Miguel Grinberg’s blog [0]. In fact his blog is a gold mine for Flask development as well.

[0] https://blog.miguelgrinberg.com/category/MicroPython

Fpga version so cover the really open issue?

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.

Can someone help demystify this for me?

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?

No - this is implemented in software on a general-purpose processor. You can't read flash contents optically with a microscope, so the software part is invisible. You can certainly identify the bits of the general-purpose processor though.

I think Lua is also and already great at embedded usage? Of course the more the merrier.

tinygo, micropytho, lua, there were a few mini javascripts but I lost track any of them

Has anybody got requests and/or full HTTPS protection working?

Can anyone comment on what parts of Python are not in MicroPython?

Have a look at:

MicroPython differences from CPython

http://docs.micropython.org/en/latest/genrst/index.html

The language is surprisingly complete; bigger differences are found in library support, even standard library support. Libraries that are memory efficient are easy to port but many Python libraries assume vast amounts of memory so it can require significant effort to modify them to use few resources.

Perhaps it would be useful to package it for mobile phones.

Have a few M5's, they're great little gadgets.

anyway to get wifi?

Already available on some devices. Notably the ESP32 and ESP8266.

Ive used the nodeMCU (ESP8266). Its arduino compatible, costs around $3 and has WiFi

Reply on news.ycombinator.com