6 ms·

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 Mic

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 https://www.youtube.com/watch?v=437CZBnK8vI

zackees 6y ago
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.
- embedpythony 6y ago
  It already does! (As long as the target supports LLVM) https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/
- mlyle 6y ago
  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.
  - neilpanchal 6y ago
    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!
  - mkesper 6y ago
    Which boards are you using and how did you chose them?
    - mlyle 6y ago
      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 https://www.adafruit.com/product/3333 and was really happy with it... but I wanted something a little beefier and to have wireless options.
- matt_trentini 6y ago
  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.
Philip-J-Fry 6y ago
TinyGo (https://github.com/tinygo-org/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.
- lloeki 6y ago
  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/ https://mruby.org/
- tolidano 6y ago
  But no REPL for real-time probing or testing, so you’re in a big-guess-recompile-deploy cycle, correct?
jokoon 6y ago
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.
- neilpanchal 6y ago
  It is not too difficult, just extremely verbose (even for a simple int arg function): https://docs.micropython.org/en/latest/develop/cmodules.html https://docs.micropython.org/en/latest/develop/cmodules.html This might help: https://github.com/stinos/micropython-wrap https://github.com/stinos/micropython-wrap
  - jokoon 6y ago
    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.
eggy 6y ago
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/ http://www.ulisp.com/ [2] https://www.nerves-project.org/ https://www.nerves-project.org/
dheera 6y ago
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.
- analog31 6y ago
  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.
- matt_trentini 6y ago
  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.
- dcmorton 6y ago
  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 https://github.com/dcmorton/esp32-micropython-image-builder
- jennasys 6y ago
  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.
IgorPartola 6y ago
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.
- stinos 6y ago
  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.
  - IgorPartola 6y ago
    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.
matt_trentini 6y ago
Hey, that's me - if anyone has questions about that then you can ama!
sitkack 6y ago
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.
- joshspankit 6y ago
  This jumps it to the top of my list of tech to explore on microcontrollers.
- matt_trentini 6y ago
  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. :)
  - askvictor 6y ago
    I only wish Micropython had a real debugger (pdb).
    - matt_trentini 6y ago
      #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 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!
    - deleted 6y ago
      [deleted]
- m463 6y ago
  PEEK POKE (who named these interesting commands?)
  - deleted 6y ago
    [deleted]
numlock86 6y ago
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 ...
- matt_trentini 6y ago
  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.
Abishek_Muthian 6y ago
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-pomodoro-timer/ https://abishekmuthian.com/butt-pomodoro-a-butt-triggered-po...
- mch82 6y ago
  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.
  - Abishek_Muthian 6y ago
jakecopp 6y ago
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 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!

zackees 6y ago

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.

embedpythony 6y ago
It already does! (As long as the target supports LLVM) https://rust-embedded.github.io/book/ https://rust-embedded.github.io/book/
mlyle 6y ago
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.
- neilpanchal 6y ago
  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!
- mkesper 6y ago
  Which boards are you using and how did you chose them?
  - mlyle 6y ago
    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 https://www.adafruit.com/product/3333 and was really happy with it... but I wanted something a little beefier and to have wireless options.
matt_trentini 6y ago
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.

Philip-J-Fry 6y ago

TinyGo (https://github.com/tinygo-org/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.

lloeki 6y ago
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/ https://mruby.org/
tolidano 6y ago
But no REPL for real-time probing or testing, so you’re in a big-guess-recompile-deploy cycle, correct?

jokoon 6y ago

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.

neilpanchal 6y ago
It is not too difficult, just extremely verbose (even for a simple int arg function): https://docs.micropython.org/en/latest/develop/cmodules.html https://docs.micropython.org/en/latest/develop/cmodules.html This might help: https://github.com/stinos/micropython-wrap https://github.com/stinos/micropython-wrap
- jokoon 6y ago
  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.

eggy 6y ago

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/ http://www.ulisp.com/ [2] https://www.nerves-project.org/ https://www.nerves-project.org/

dheera 6y ago

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.

analog31 6y ago
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.
matt_trentini 6y ago
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.
dcmorton 6y ago
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 https://github.com/dcmorton/esp32-micropython-image-builder
jennasys 6y ago
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.

IgorPartola 6y ago

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.

stinos 6y ago
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.
- IgorPartola 6y ago
  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.

matt_trentini 6y ago

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

sitkack 6y ago

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.

joshspankit 6y ago
This jumps it to the top of my list of tech to explore on microcontrollers.
matt_trentini 6y ago
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. :)
- askvictor 6y ago
  I only wish Micropython had a real debugger (pdb).
  - matt_trentini 6y ago
    #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 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!
  - deleted 6y ago
    [deleted]
m463 6y ago
PEEK POKE (who named these interesting commands?)
- deleted 6y ago
  [deleted]

numlock86 6y ago

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

matt_trentini 6y ago
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.

Abishek_Muthian 6y ago

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-pomodoro-timer/ https://abishekmuthian.com/butt-pomodoro-a-butt-triggered-po...

mch82 6y ago
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.
- Abishek_Muthian 6y ago

jakecopp 6y ago

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 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!