Hacker News Reader

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

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?

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.

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.

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.

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

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

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!