MicroPython – Python for Microcontrollers | Hacker News Reader

MicroPython – Python for Microcontrollers

micropython.org

251 pointsTomte102 comments

I did a lot of product development using Micropython over the past year or so. There are certain things it is very good at - one is rapid prototyping. For instance it’s a lot easier and faster and less verbose to quickly get some http server communication going on the ESP32 in Micropython rather than the C equivalent.

The downsides are somewhat dramatic though - it’s, of course, a lot slower and hungrier for memory than the C equivalent code, but it’s also still missing a lot of API’s and fine grained control, at least for the ESP32. For instance, what finally made me switch to the ESP-IDF was complete lack of support for ADC2 on ESP32 in Micropython. Having to recompile the Micropython firmware to change a good chunk of the configuration parameters was also annoying because it takes a decent amount of time to compile and reflash firmware.

Bottom line is that Micropython is a great project for certain things - some home automation and simple sensors. On things where performance doesn’t matter or isn’t bottlenecked by the Python interpreter (like simple HTTP communication) it’s great. It also has a surprisingly robust open source driver ecosystem, provided you aren’t trying to do anything fancy with SPI.

It falls apart when you need to work with it professionally though. So use it to build and test your product, but rewrite it in C/C++ when it gets closer to ship time.

I had a similar experience, however the “native” and “viper” code emitters do a very good job of allowing you to optimise performance bottlenecks. It’s a lot like Cython.

https://docs.micropython.org/en/kookaberry/reference/speed_p...

The company I work for uses MicroPython commercially to build medical devices. It hasn't fallen apart for us.

Indeed, it's helped deliver high-quality solutions quickly...

You have to have the right people. They have to like Python and want to use it, but not because they think "C is too hard". They have to be happy writing Python code and confident enough to write modules in C and work on MicroPython itself.

There is some steps necessary to go from "prototyping MicroPython" to "production MicroPython" and many people either forget about them, are not skilled enough to do them (which is fine, MicroPython is about onboarding people to embedded as well) or they feel like these steps make using MicroPython pointless.

> You have to have the right people.

Yes, true! I presented a lightning talk to colleagues on "Ingredients for Commercial MicroPython Success". One of the key points is "People are critical". Maybe folks here might find it useful:

https://docs.google.com/presentation/d/e/2PACX-1vR3DJk-dNTvE...

Isn't it considered SOUP ? https://en.wikipedia.org/wiki/Software_of_unknown_pedigree

Yes, but that doesn't give you a free pass. :)

My colleague gave a good talk on how we use MicroPython, as SOUP, in our devices:

https://www.youtube.com/watch?v=YovngSLXoxw

Can you guarantee you never run out of ram? Or do you just restart regularly?

(I typically am to scared to even use malloc on a microcontroller...)

Managing memory use is one of the key concerns, particularly if you require long uptimes. Memory fragmentation can be a serious issue if you ignore it.

But MicroPython's gc is fairly simple and easy to reason with. We've gotten a lot of value out of two useful tools/techniques: 1) Rendering memory use over long periods of time (micropython.mem_info(1) will output a text representation of how memory is used). It's pretty obvious when memory use starts expanding. 2) Turning the gc off in key unit tests so we can be sure critical sections do not allocate (an exception will be raised if memory is requested from the gc).

But, of course, memory use in any embedded application is critical.

That's worrying. I can't think of a less appropriate application for something as fragile as Python.

The MicroPython interpreter is very robust and well tested. We test our devices extensively. You need to pay attention to gc performance, memory use and fragmentation but this isn't our first rodeo!

Systems are typically fragile because of poor system design not language choice. I've worked on many C and C++ systems and there's nothing inherently more robust about them. Some would argue that the various ways you can trip over UB makes them more fragile...

> Some would argue that the various ways you can trip over UB makes them more fragile

That is definitely a factor! But I probably wouldn't pick C++ for a medical device now anyway - I would go with Ada or Rust.

> Systems are typically fragile because of poor system design not language choice.

Poor system design and language choice are both factors. You can work around language choice with a shit load of testing, but it's still much better to use a language that gives you stronger guarantees. Also the choice of language affects system design, so it's not like you can just ignore it.

For example even ignoring anything memory related, Rust's borrowing system pushes you towards code that has fewer bugs. Python... well, not so much!

Bashing Python, or language-bashing in general, makes you sound like an immature and unprofessional programmer. Python is perfectly fine when used in the proper way by a knowledgeable professional, and Rust can be a dangerous tool when used by a beginner. It takes the knowledge of a tool to use it properly and safely; just because someone hit themselves on the head with a hammer doesn't mean hammers are inferior to nail guns and unsafe, they still have their uses in several areas where nail guns aren't the best choice.

Sure, Python has its place. But that place is not where you need the software to work extremely reliably.

If pointing out relevant and real differences between languages counts as "bashing" then I'm not sure how you are meant to discuss it.

Language choice does have an effect on program robustness. That's just a fact. And it's also pretty indisputable that Python lacks many features that help to write robust code.

Pretending that isn't true is immature and unprofessional.

It has some pros of course - having a REPL is good for experimentation, and it has a great library ecosystem for example. But neither of those are particularly important for commercial medical devices.

Please explain what you think is important about commercial medical devices, because having worked in the industry I can tell you the FDA is the hurdle and it's going to be as hard to convince them that C or Rust or Ada is safe to use for a medical device as it would be to convince them that Python was safe, and in the process you will certainly be ensuring there are safety controls for each item on the software FMEA, whatever your chosen ecosystem.

I'm talking about actually making reliably devices, not just satisfying regulations.

> Please explain what you think is important about commercial medical devices

I'm not exactly sure what you're asking here. Medical devices are often safety critical. They need to work extremely reliably. That's obvious; I think I must have misunderstood your question sorry.

> That is definitely a factor! But I probably wouldn't pick C++ for a medical device now anyway - I would go with Ada or Rust.

I would like to as well, but that is very much not an option in most hardware projects at the time of writing of this comment. The ecosystem for these kinds of projects as a business in hardware is just too young to make it reliable enough to be shipping in a reasonable amount of time. Currently you really have very few choices in mainstream embedded programming for languages in a generic sense. You either work in c or c++, or you use micropython - and even micropython is young enough to invite some skepticism. No other ecosystem rivals these, though I do look forward to some promising commercial embedded Rust projects in the next few years.

I agree. Using MicroPython in medical applications is with all due respect worrisome. It's not meant to be for crucial tasks and definitely not optimal at all for MCUs. It's really meant to be for simple, hobby applications. It's too high-level (synonym of inefficient) for MCUs. C and Assembly are the way to go for these critical applications (that's why NASA & SpaceX use C and assembly in embedded electronics). Reliability, repeatability and fast performance is key.

Thanks for telling us what MicroPython is for. :P

(BTW, I can't vouch for NASA or SpaceX, but it's no secret that the European Space Agency has been working with MicroPython for many years.)

I don't disagree that reliability, repeatability and fast performance are (often) key; but our experience suggests that these can be (usually, if not always) achieved with MicroPython.

One thing to add from my experiences: it's dramatically more accessible to beginners than Arduino and way more useful for building one-offs/prototypes as well.

My personal experience was the opposite. I own two identically equipped boards: the Seeed Studio ArchMix and the Teensy 4.1

On the archmix, I managed to boot up and that’s about it. There was literally a REPL and I was able to blink the LED and then I couldn’t proceed further, where was I supposed to code? Bad experience.

Teensy: connect the board , fire up the teensyduino ide, choose an interesting example from the drop down menu, run it, rinse and repeat until you are familiar with idioms for all sorts of things, real hardware examples they do real things, real peripheral support in the form of examples

I agree that the user experience, onboarding etc. are very well executed for Arduino (and especially for the ESP32 port of uPython could use some polishing)...

> rinse and repeat until you are familiar with idioms for all sorts of things

Except that the idioms you learn are really not suitable for anything but toy examples. Arduino is rotten from the core: "setup", "loop" and "delay" are the worst imaginable way to write embedded software, yet everyone coming from Arduino thinks this is how well written embedded software should look.

Indeed, those obstacles are easy to overcome, but someone has to point a beginner in the right direction.

As I understand it, the ability to program Arduino in C was originally kind of an accidental feature of Arduino. The original Arduino downplayed C, and referred to the programming language as "wire." A few people (myself included) discovered that by simply ignoring those constructs, Arduino becomes a full fledged C development environment. But I think doing things "the right way" on a microcontroller really requires learning concepts that are not beginner friendly, like interrupts, and for that matter, electronics.

> "setup", "loop" and "delay" are the worst imaginable way to write embedded software

I agree with "delay", but why do you say setup and loop are the worst imaginable way to write embedded software?

> why do you say setup and loop are the worst imaginable way to write embedded software?

Because there's neither abstraction nor ways to combine things. Say you have a device that needs to do two things, and you look up some examples of how to do each thing. Each example is going to have its own loop() function--but how do you combine them? There's no notion of tasks or threads. There's no abstraction for device drivers. Arduino is a system that paints you straight into a corner.

[edit to add] Any reasonable software environment needs to provide three things, quoting "Structure and Interpretation of Computer Programs" here [1]:

* primitive expressions, which represent the simplest entities the language is concerned with,

* means of combination, by which compound elements are built from simpler ones, and

* means of abstraction, by which compound elements can be named and manipulated as units.

Arduino only provides the first.

[1]: https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

You don't have to use `setup` and `loop` tough. We use Arduino as a library in C++ using PlatformIO as tooling. Best of both worlds.

The thing you are hating on is pretty much this file: https://github.com/arduino/ArduinoCore-avr/blob/master/cores...

Arduino is C++ with some boilerplate and a library.

But these `setup`, `loop` and `delay`, as well as the terrible "IDE" are central to the "simple" user experience of Arduino and are, imo, false friends. Teaching people busy loops and blocking behavior from day 1 is counterproductive because you'll have to unteach them later and jump through hoops to avoid them. Arduino libs are strongly optimized for "easy", not efficiency and flexibility.

I did just fine and so are millions of other people.

Using Arduino will not magically rot your brain and make you unable to ever learn other things. It will however get you started quickly and therefore give you an in. I started using Arduino in a student job, then used Micropython, did my masters thesis on using Micropython on cubesats and now I run a team of 15 hardware engineers.

All of this happened because I got started with easy beginner tools. There was no one to teach me the "real" way. The people preaching the real way and railing against simple beginner stuff usually don't write tutorials, build easy to use devboards or write easy to use libraries.

Why are "setup()" and "loop()" bad? setup() is just main().

You need to buy a Pyboard from MicroPython, or Adafruit Express board for CircuitPython. Then you get a bunch of onboarding tutorials.

CircuitPython is very nice for beginners, Adafruits tutorials are gold. Switching to MicroPython is very easy (CircuitPython makes some simplifications to be more beginner friendly, MicroPython aims to be as "professional" as possible).

> One thing to add from my experiences: it's dramatically more accessible to beginners than Arduino and way more useful for building one-offs/prototypes as well.

Yeah, right. Now if i find out why it gives syntax error on a perfect part of code.

Yes, I have been using MicroPython on ESP32 and RPi Pico. For projects like home automation, it was super easy and handy. When I started building a game console using RPi Pico (https://github.com/codetiger/GameTiger-Console), I had to rewrite as Python interpreter takes a lot of memory and leaves very little for the application. In my case, I had to avoid using Framebuffer on MicroPython. After switching to C++, its all in your control and take lot of time to write the same simple things

I think what used to be BASIC / Assembly relationship back when hardware comparable to ESP32 used to take a whole desk, is now Python / C++ instead.

> It falls apart when you need to work with it professionally though

More accurately: it falls apart when you need it professionally :) Totally depends on the usecase.

A fair point, but is it an inaccurate statement to say it falls apart when most need it professionally? I can easily accept that MicroPython makes sense for certain use cases, but to recommend it generally for people when I feel like I wasted many hours down the rabbit hole seems to be a bad idea - and I feel like your comment implies it's something like 50/50. So perhaps it's more accurate to say that there are a few pointed use cases when Micropython makes sense to ship with, but at least 80% (and I feel like I'm being very generous here with that number) of people are going to want to go the c/c++ route at the time of writing this comment in 2022, though I could see that changing in the future.

As an aside, I really like Micropython and I spent a LOT of hours trying to make it work at a production level for my use case, but in the end I relented and had to write my software in C - it's not like I'm some low level language purist here. And it's not like my use case is what I would consider super edgy either - a fairly typical project with ESP32 where you wake sensors up on a very conservative basis (once per hour), take basic readings and send the data over HTTPS.

What did you end up using MicroPython for?

Frontend for writing behavioral experiments. So backend runs C++ signal processing etc, graphics display, or whatever we need, all of that has bindings for MicroPython.

Works very well, but: it's still Python. Great, but dynamic so not the best suited for larger applications in my experience - no matter how well-architected the code is. Becomes just really hard to refactor without breaking anything.

My company uses it for medical device development, ama if it will help!

Very cool.

Are you prototyping or manufacturing at scale?

What kind of sensors have you attached?

Manufacturing at scale. Though these are medical - not consumer - devices so we're not talking hundreds of thousands of units. Think high-quality, injection molded, moderately sophisticated devices. Typically hundreds and up to several thousands of units, depending on the project.

We use all manner of sensors; temperature, pressure, cap touch, photodiode detection, cameras.

Did you try running it on top of Zephyr?

I don't personally use the Zephyr port, though it has plenty of potential. But it's worth sharing that the Renode folks have put together a MicroPython on Zephyr dashboard to show that at least 90 of their simulated boards appear to reach the REPL:

https://zephyr-dashboard.renode.io/dashboard-micropython.htm...

Any of those that are passing would be a good board to choose to start with.

A possible alternative to MicroPython is Nim - it's a strongly typed language with Python-like syntax that compiles down to C. Since it compiles to C, it can use existing C libraries without much fuss (just wrap signatures as needed), plus there's no need for a "micro" version of the language.

Several members of the community have been working on improving the embedded ecosystem: although I haven't played around with either yet, the nesper library (for the ESP32) and ratel (generic framework: tested for the Arduino/AVR) have been recommended.

https://nim-lang.org/

https://github.com/elcritch/nesper/

https://github.com/PMunch/ratel

I've been using Nim and Nesper for the firmware of a device I'm making, it's been mostly great. Nim's C interop is painless, anything Nesper hasn't already wrapped can generally be pulled in from the official C libraries in one shell command. My only headache with Nim on the ESP32 is that the official framework doesn't provide a full POSIX implementation so some stdlib functions don't work.

https://github.com/khogeland/pxed/

Hey awesome to hear others are using my Nesper! Nice to read through your repo and see what style of Nim coding you used (low level C-like constructs vs higher level Pythonic ones). Feel free to post PR's, I try to merge them once a month.

Nim, Zig, Julia, Rust, so many languages lately ... anyone else with language-choice anxiety?

Not really. Probably only a single-digit percentage of software developers will ever get to use any of these professionally. Howl in protest if you will, but the truth is that all of these (and more) are mostly the domain of students and hobbyists.

If you are already in the industry, and part of the 90+% unwashed masses, then you already know this. If you are a student or hobbyist who hasn't clued into this reality yet, then there's no need for "language-choice anxiety". Play with whatever you want to play with, and once you graduate you should have no problem transferring that knowledge to whatever language your first real job actually pays you for (e.g. Java, Python, C#, etc).

This is mostly true, but (I cannot believe I am going to do this), Rust is in a different tier compared to the other languages in the list.

From the last who is hiring thread:

Zig =0 mentions

Nim = 0 mentions

Julia = 2 mentions

C# = 4 mentions

C++ = 12 mentions

Rust = 13 mentions

Java = 18 mentions

JavaScript = 30 mentions

Python = 50 mentions

The threads here are not indicative of the overall market and 1 mention != 1 job, but the numbers above are pretty much in line with the proportion of offers I am seeing elsewhere.

I should not have chosen Pascal as my primary programming language.

It is not even mentioned when looking for uncommon language mentions

While at it dont forget TinyGo. Im a hobbyist occasionally working on potentially commercial ideas. ARduino is great to start learning. PlatformIO i found very supportive with tools for everything I needed and wide board support. Used to code a lot in Python. My next project i will use TinyGo to see the degree of correspondence with full desktop Go and beyond that im inclined to try Ada next as for bare metal code the idea of using Ada just seems to make a whole lot of sense given its application to control systems over the decades.

My 2c

Nim is a very good choice because it generates tiny binaries while having a very expressive syntax.

It's the closest language to a static typed Python.

Also it uses GCC, which supports most microcontrollers.

For micro-controllers having a choice in language is very new and there is still very few languages to pick from. Chip vendors only support C/C++, sometimes only barely.

Many languages (if it is AOT compiled and uses LVVM you can probably get it running on a uC) have POCs for running on an a uC, but often lack the HAL (libraries to use all the peripherals).

If you work with the developers of those projects let them know that many details of an embedded CPU are generated by code. It's an important step to break the cycle of re-encoding information produced by machine in microcontroller standard libs.

I think with current parts the only way would be to focus on RISC-V, but who knows. They might have better luck talking to vendors.

MicroPython - https://news.ycombinator.com/item?id=24166861 - Aug 2020 (147 comments)

MicroPython and the European Space Agency - https://news.ycombinator.com/item?id=9699798 - June 2015 (28 comments)

MicroPython: Python for microcontrollers - https://news.ycombinator.com/item?id=9558969 - May 2015 (19 comments)

MicroPython – Python for microcontroller - https://news.ycombinator.com/item?id=8177695 - Aug 2014 (17 comments)

> Micro Python - https://news.ycombinator.com/item?id=7839699 - June 2014 (1 comment)

1 comment is not a very big discussion

I include 1-comment threads in 'related' lists, especially when they're old, because it can be interesting to see what the 1 comment was from 10 years ago or whenever.

However, you're right about that case because the 1 comment was not that interesting. I'll take it out of the list above. Thanks!

I find reading untyped code unnecessarily difficult.

Just this week I came across Swift for Arduino, and SwiftIO, both Swift language solutions for low level boards.

I'm looking forward to giving them a spin.

https://www.swiftforarduino.com

https://www.madmachine.io/

That looks really interesting. Swift is - in my opinion - probably the best language out there. If wish it would get more traction on server side and on Linux too.

Does micropython not allow typing? That would be odd. I mean, i see how running it with mypy on an esp32 does not work, but the hints can be evaluated on the dev-platform and used by the developer and his IDE/Linter/whatever.

It allows typing as you'd expect.

Edit: More specifically, the parser correctly ignores type hints.

i do embedded programming as a hobby for high power rocketry ( altimeters, orientation sensors and, someday, control, and other stuff ). Micropython is great for what I do and the repl is especially handy (i just start a screen session and there it is). I've tried lots of different boards but settled on the stm32 Feather from Adafruit. Adafruit's circuit python is really handy because they have a lot of drivers already written for common sensors and other things. Heh it was a bit of a shock when i realized in embedded programming you read need to read a datasheet and write your own device drivers.

I originally tried C using hardware debuggers and the whole 9 yards. It just took too long to get the toolchain setup and all the init required to get to a blinking LED (the helloworld of embedded). I also tried platformIO which looks very very cool but my boards weren't 100% supported. Next was the stm32 ide which helps you get a lot of the low level config off the ground but it still seemed the long way around. I also tried some of the hardware OS's like FreeRTOS but, again, not my cup of tea and "operating system" means something very different in the embedded world than what i'm use to.

i have a pi zero w and it really has my ears up too because i can run the same micropython there, can ssh to it directly, has a file system, runs linux etc. I have a really convenient pwm control board with an i2c interface so the non-realtime operating system on the pi zero isn't so much of an issue for what i do.

I use a hybrid architecture that is working quite well for interactives in my little corner of the museum industry. I pair a raspi running either node-red or python with a Teensy coprocessor running embedded C code and handling the IO. The two communicate via UART serial via either firmata or a custom protocol as the project requires. Having the Teensy handle IO lets me tie directly into pin interrupts, FlexIO, DMA and other hardware goodies with the very well written PJRC libraries. At the same time, the raspi handles any network connectivity, timekeeping, controller coordination, and HDMI output. I get all the rapid prototyping ability of python or node-red while at the same time having all the raw bit banging power of C on a Teensy 4 at 600mhz.

That's interesting. What firmware are you running on the Teensy? The 3d printer software Klipper uses a similar architecture, and I'm very impressed at the general purpose motion control firmware they've written for that project, to the point that I'm strongly considering using it in my own (non-3d-printer) projects. Did you write it yourself?

I hope we see JS for microcontrollers fast enough so we can enjoy bloated Electron apps running on microcontrollers. :)

I mean, who wants anything but the fastest, leanest languages running on microcontrollers?

https://www.espruino.com/

> who wants anything but the fastest, leanest languages running on microcontrollers?

Me. I value speed and comfort of development more than micro-optimizations. Coincidentally this is why Electron is popular.

Electron needs to work on it's debuggability.

Seriously. That crap is a nightmare. Especially in production mode. Or maybe I just need more time with node, but trying to debug the main loop sans IDE is an act best described as excruciating. Once you start spawning new processes as well, you end up having to custom roll code to massage the port the spawn emits the inspect-brk for, which can end up getting quite complex if you have enough different entrypoints.

That's good bait. In fact, I've almost reflexively down-voted you after reading the first line.

Hardware utilization and capacities matter if you have kilobytes of ram and megahertz of cpu speed

My Bangle.js smartwatch says hello. Slowly.

If you have kids and you want to give them some experience with physical computing and MicroPython, can I suggest our resources at https://projects.raspberrypi.org/en/pathways/pico-intro

They're pretty simple and very creative, and the Raspberry Pi Pico is about the only Raspberry Pi device you can get hold of at the moment.

We've created an abstracted package called picozero, that makes turning on LEDs and reading sensors pretty simple in MicroPython. It's very easy to install and use, if you're using the Thonny editor - https://github.com/RaspberryPiFoundation/picozero

Another alternative is Toit: https://toitlang.org

I recently wrote a Toit version of the lessons for the MakePython ESP32 starter kit. That makes it easier to start with Toit, but it also gives a nice comparison between the two.

MicroPython: https://www.makerfabs.com/desfile/files/Get-Started-MicroPyt...

Toit: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...

Anybody has experience with how it stacks up against TinyGo [1]?

[1] https://tinygo.org/

How large are typical binaries with TinyGo?

Go is a great tradeoff, it's about as easy to learn and fast to write as Python for prototyping, while being a much slicker, faster, compiled language. But will the runtime fit a tiny MCU PROM?

edit: A Hello World written in Go and compiled with TinyGo is just 10kB! https://tinygo.org/getting-started/overview/

It also works on Arduino Nanos, has builtin support for UART, SPI, I2C and PWM, and can also generate Linux binaries. This is a great find!

Yeah, it's a completely different runtime. I think the purists might argue that it's a completely different language, but it feels similar enough that you don't get too upset about the occasional language feature that doesn't work.

I remember using time.Format(time.RFC3339) in a project once. Seemed impossible to have such convenience on a microcontroller, and I probably paid a lot for it, but it did work perfectly.

If performance is adequate (say 1/3 of C, or 10x faster than Python), this is a big deal.

It means we get a simple, nicely designed language with a great standard library, short development times, and small, performant binaries once compiled. Go on MCUs was out of question because of its runtime size. I'll keep an eye on this.

See also Adafruits fork CircuitPython, modified to be easier for beginerers.

https://circuitpython.org/

MicroPython is used in various electronic badges at hacker camps in the Netherlands and Germany. See: https://github.com/badgeteam/

Interesting to note that MicroPython can also output MIDI, like QMK but, in my experience, much easier to work with. I got a little 4x4 micropython numpad and turned it into a midi controller.

Been trying to find a 40%-ish keyboard with micropython so I can do the same with that, but no luck so far other than DIY jobs

Edit: Apologies, was thinking of CircuitPython, which it turns out is a fork of Micro Python. Not sure if micro can also output midi

For those new to MicroPython or to the ESP8266 line of microprocessors here is a talk that I gave at a PyCaribbean conference in 2017. [1]

Its a bit long winded but I tried to touch upon everything that a new entrant to the space would want to know to start playing with the board immediately.

I am not a natural public speaker so please excuse my verbal (or other) tics.

I have also linked the presentation PDF. [2] You can scan the entire PDF in less than 10 minutes to get the gist of the 45 minute+ YouTube video.

[1] https://www.youtube.com/watch?v=6ctB8VMm6RA

[2] https://github.com/spicecoaster/pycaribbean2017

Hm, interesting. I remember the upcome of Arduino: They advertised their system (setup() once, loop() forever) as very friendly towards tinkerers using 8bit uControllers. Anybody could jump straight ahead without setting up anything in ASM let alone programming the EEPROM externally.

With hardware progress (ESP32 is 32bit/80MHz+), it seems another iteration happened: processing power is traded again for accessability/usability. In this case python.

I could see python becoming the predominant system for 32bit micro controllers. But for small 8bit systems that just read out a sensor and turns of a switch, that will stay in the realm of Arduino and C.

All of this only applies to hobbists. Serious shops have been using 32 bit mcus since the mid 00s and if you even think about putting an interpreter in there, a senior software engineer will probably kill you in your sleep. Rightfully so.

Not in my experience; 32 bit MCUs are cheap and powerful these days and reducing the development time by a significant margin - our projects have seen 15-30% reductions compared to our equivalent C estimates - is well worth considering. I'd be more worried about senior engineers that didn't take that seriously.

I personally like ulisp as it allows proper dev on an rpi pico

If you cannot even fit MicroPython on to your device, you could always try Snek:

https://sneklang.org/doc/snek.html

https://lwn.net/Articles/810201/

The guys at TIC-80 had a proposal of embedding mpython to the engine, so you will be able to write in python: https://github.com/nesbox/TIC-80/issues/935

And with a little bit of coercing, it can be used the other way: To embed Python in Desktop apps giving you a fairly light-weight Python interpreter.

I used it for a little Windows macro program ( https://github.com/seligman/microkeys ) . I got it to a POC stage to solve the precise problem I have, basically I needed to be able to do some simple text parsing on whatever's in the clipboard and type out the results, so I'm happy. I'm always curious if it potentially fills a need for others as well.

I come from a background of C and C++ on the Atmel Mega and XMega controllers. I tried using Micropython on ESP32 to control some small OLED displays which had an 8 bit bus with a 6800 style interface. It was too slow.

I would still like to use micropython, but I need to figure out how to write certain pieces like the display lib in C.

What are the advantages compared to something like Lua, that's more designed to call out to C code?

Rapid prototyping using syntax similar to that of one of the most widespread programming languages is where it really shines.

Micropython is very nice... I use it on my esp8266 boards for relatively simple stuff.

Another alternative is rust. https://github.com/rust-embedded/awesome-embedded-rust

I intend to have a try of both rust and tinygo.

Micropython is only ok on an esp32 with psram.

"...only ok on an esp32 with psram"??

I use it on many devices (rp2040, nRF52, ESP32 and, professionally, on STM32). It's an effective platform on all of them.

I think rust is the way to go, it provides granular control if needed and strong type annotations and the borrow features. however, C is here to stay for an eternity.

COBOL and Fortran as well, so what.

Do Numpy and SciPy run on this?

No, but there are some libraries that try to provide cut down versions: https://github.com/ComplexArts/micropython-numpy, https://github.com/v923z/micropython-ulab

A language with meaningful whitespace and indentation does not make a good language for UART or other serial interaction. At the point you can use a higher level interaction, why stop at Python? Go full codeless checkboxes on webpages.

If the alleged problem that micropython solves is complexity of actually coding microcontrollers, why settle for Python, which can only ever wrap/call native functionality that is hidden like a black box?

Is this really easy or useful at all?

A superior solution already exists called “Arduino” that removes most of the complexity of microcontroller development, comes with an ide and loader tool chain and you press a button and Bingo, your code is running directly on the metal of a variety of hardware, which these days includes some of the most powerful microcontrollers out there such as the teensy 4 and its iMX RT1062

I have an archmix with the identical microcontroller, but with a micropython runtime, it was sold by seeed studio and it sits in the box it came in as I never managed to do much with it.

There’s really no effective way of avoiding hardware with microcontrollers, as you expressly access it’s features with no operating system and only a HAL or CMSIS for an API, most of the time.

By the time someone wraps all hardware functionality in a scripting language, much developer time has passed and it’s likely that features are missing or broken, and basically the noobs are still out of luck waiting for all promised supported functionality and discouraged from learning anything about the actual hardware platform

> A language with meaningful whitespace and indentation does not make a good language for UART or other serial interaction

I mean its almost irrelevant to the ability to handle serial, unless you are exec'ing raw serial, which is going to make everyone sad.

I have found that bitbanging in python a bit of an arse. Using the struct library isn't as forgiving (or dangerous) as it is in C. But on the flip side it does force you to properly define your binary serial protocol, unless you want loads of exceptions.

Arduino is grand, and fun. But where the python like languages shine is higher level stuff, like networking.

> A language with meaningful whitespace and indentation does not make a good language for UART or other serial interaction.

This is a nonsensical nonsequitur. The whitespace of the language you use has nothing to do with what communication it can do. Python works great for talking to my plotter over RS232.

> A language with meaningful whitespace and indentation does not make a good language for UART or other serial interaction.

Whenever I see someone complaining about Python's use of whitespace as syntax, I think to myself "This person poorly formats their code".

If you're properly formatting code, there's no reason to complain about it. You might occasionally copy/paste code from where that doesn't properly encode the whitespace, in which case yeah it might get messed up, but that's rare in my experience.

Very useful

Reply on news.ycombinator.com