MicroPython running “bare metal” in the browser via unicorn.js | Hacker News Reader

MicroPython running “bare metal” in the browser via unicorn.js

forum.micropython.org

103 pointsm_eiman32 comments

"Bare metal" meaning that instructions run "natively" on a simulated Cortex-M3 microprocessor via an emscripten-compiled stripped-down version of QEMU.

It's a cool way to quickly test out performance and iterate on micropython scripts built for microcontrollers; not a python engine in the browser, sandboxed and running instructions directly.

What's the german word for the mixed feeling of incredulity, disgust, awe and respect that I'm getting right now?

We don't have one, but you can make your own, e.g. Ungläubigkeitsekelehrfurchtsrespekt.

Schädengurken

Google Translate translates that (DE->EN) as "damage cucumber".

... yeah that about sums it up.

I swear half of hackernews posts are just new ways to nest some combination of interpreters, emulators and runtimes within javascript.

I'll bet a significant fraction of the uses of Emscripten are due to its effectiveness as a "yo dawg" or "*ception" meme generator.

"New". Haha. That's generous.

This is a neat demo, but its real value for me was learning about MicroPython. Whenever I've asked friends about a small, fast, embeddable scripting language the answer has been Lua. I favor Python much more than Lua so this project is attractive.

Some bits on how eLua compares with MicroPython from their comparison page[1]:

> eLua, with LTR patch, boasts only 5.42K RAM usage after book, down from ~25K with unpatched Lua. (ref: http://www.eluaproject.net/doc/v0.9/en_arch_ltr.html). uPy offers ~540 bytes usage after boot (10 times less than patched eLua), and truly can boot and accept commands with 2K heap.

[1]: https://github.com/micropython/micropython/wiki/MicroPythonV...

> We have recently developed the ability to run MicroPython "bare metal" in a web browser. This is acomplished using unicorn.js, which is an Emscripted version of unicorn, which is a stripped-down version of QEMU.

I don't think "bare metal" means what you think it means.

I don't think ""bare metal"" means what you think it means.

yeah, he misread ""bare metal"" for "bare metal".

I tried to the whole thing in a VM, so I can attest that it works on """bare metal""", as well.

http://pypyjs.org/ , https://github.com/pypyjs/pypyjs

Sadly, current implementation is buggy and has not been updated for 2 years.

The Cortex-M3 emulator in browser is extremely useful without the MicroPython part --- a C++ toolchain can equally take advantage of it.

If you are interested, here's the emulator they use: https://alexaltea.github.io/unicorn.js/

This is cool! It's sad that front-end technologies are dominating. No browsers have added any back-end languages to the front-end, and instead, javascript is starting the dominate the back-end (i.e. node.js).

Take a look at WebAssembly: http://webassembly.org/docs/use-cases/

I wish n-gate.com took requests...

I would be surprised if this doesn't get a nod.

Bare metal in this case is far from being 'Bare' or 'Metal' for that matter. Impressive none the less.

For a completely different approach, Grok Learning exposes MicroPython to the browser via a WebSocket: https://groklearning.com/microbit/

We find this approach works fine, assuming you have a stable internet connection.

I'd be curious about performance vs raw javascript. I mean it's obviously going to be slower in a VM but by how much?

lots

>>> sum(x for x in range(100000))

did not complete even after several minutes.

Mind that the "clockspeed" is noted as 100khz.

Kind of a neat project, but I'm not sure if it is very useful. Maybe emulating for testing reasons.

A very useful project for anyone learning python & coding micro controllers eg. students.

Wouldn't it be better to have students learn on hardware itself? I guess if the chips are write only or are too hard to flash it would make since. Or if cost was a limiting factor.

> Wouldn't it be better to have students learn on hardware itself?

You can probably iterate more rapidly on the emulator; it's not like this and real hardware are mutually exclusive, just as using, say, an Android emulator in development and also real devices aren't mutually exclusive, but things people do together.

“Wouldn't X be better?” is only meaningful if the options are mutually exclusive.

Generally speaking, yes, it would. Micropython runs on both esp8266 (a couple of dollars for a board) and micro:bit (designed for education); so cost isn't a factor. Uploading/flashing code is annoying on the esp8266 (though decent tooling would assist with that). I think for students real hardware is much more useful - this is probably going to be more useful for people actually trying to build something (not that students should be excluded from that, but the target is different)

> Uploading/flashing code is annoying [...]

A nice thing about MicroPython is that you only need to flash the chip once - at least if it has enough flash storage to support a file system. Once flashed, you can work on a REPL (over either UART or WLAN) and write files.

Indeed; although tooling to easily get files on there is still pretty immature (way too hard for beginners)

Reply on news.ycombinator.com