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