Kaluma: A Tiny JavaScript Runtime for RP2040 (Raspberry Pi Pico) | Hacker News Reader

Kaluma: A Tiny JavaScript Runtime for RP2040 (Raspberry Pi Pico)

github.com

76 pointstosh18 comments

    npm install -g @kaluma/cli

    kaluma flash index.js

This installs kaluma, finds the connected device, uploads the code and runs it. Love this simplicity, sounds like it was made the right way. Is there any posts with benchmarks? Very interested about the timing limits of the event loop implementation such as setInterval(()=>{}, 1); and other cpu heavy stuff like math stuff and pin output change speed from javascript.

That's really neat, a lot of times when I see js/ts used in the embedded space, there are a lot of uncanny things coming from using js/ts in my web projects. For example some projects offer TS support but the typings are either all anys or not configured correctly. They also often require lots of random software to flash, I like that this seems to integrate well with npm/node.

In short, in my experience it's good for toy projects but nothing "heavy"

> Powered by JerryScript.

Just to call out that it isn't a new engine, just a runtime on top of JerryScript (which isn't to diminish it, just to clarify).

https://jerryscript.net/

Does QuickJS https://bellard.org/quickjs/ not compile to/run on the RP2040?

Probably not using the standard version quickjs since it uses syscalls and all, but (with some workarounds with threads/syscalls/fs) it could probably run.

That reminds me of this (open smart watch with a js scripting engine): https://shop.espruino.com/banglejs2

https://github.com/espruino/Espruino

Related to Sprig, which is also on HN front page today:

https://news.ycombinator.com/item?id=33451148

This is a super cool project, it's fun for prototyping with Web Serial API, so you can have a custom web app, custom controllers... sky's the limit.

how does it compares to micropython?

Would be especially interesting to see how robust it is. Micropython on the Pico can get bricked effortlessly and needs re-flashing to get back in order, so if it's not as fragile it would be a decent contender.

how do you brick a board with micropython effortlessly? ...i'm use to the word "brick" meaning unrecoverable as in "it's just a brick now". If you can fix it by re-flashing then it's not bricked as I understand the term.

We need a word for "broken in a way that requires going out of the comfortable path to fix".

In my mind brick also meant unrecoverably dead but it seems the meaning has now drifted to what I wrote above and to access the old meaning one needs to specify "permanently bricked".

As for how to mess up micropython: If you load a main.py that has an infinite loop (common on micro controllers because there is no os) then the board will get stuck in that loop as soon as power is applied and your computer can't get a word in because it's no longer listening. Now you can't upload a fixed main.py with a way to break out of the loop.

To fix you need to hold the button while powering on. This puts in in flash mode and you can reflash micropython. Or in my case, flash a different special firmware that blows away all the .py files I had on there because main.py was still there when I just reflashed micropython the first time.

Yep that exactly, which is interesting as the ESP32 in comparison usually still manages to connect and lets you break execution despite being stuck in a loop with main.py, even with blocking timers set up. Frankly the WebREPL on the ESP is about as reliable as the Pico is via USB cable.

I've never lost any code on the ESP, but on the Pico just as you're nearing deployment and want to test run at boot you run into the easy pitfall of having to delete all of your files to unbrick the thing. Luckily I hadn't written much by that point yet.

I'd assumed that it's because the ESP runs the repl backend and the user code on separate cores, but the Pico is also dual core which would mean it could do the same. Yet it does not. I'm more convinced that the implementation is just kinda bad instead.

> If you load a main.py that has an infinite loop (common on micro controllers because there is no os)

Whether a loop is infinite or not doesn't depend on the presence of an OS. Were you thinking of "tight loop"? Now since Python is interpreted, the loop will never be all that tight, interrupts will still be handled. If you experienced that a ^C from the (USB attached) serial console didn't interrupt the program, that warrants further investigation methinks.

The problem arises when you develop your main.py by always running it over usb where you can (usually) ^C out of problems. Then as you near completion you actually upload main.py to the pi pico to see how it will work in the field running off a battery. Turns out you neglected some detail or other and it doesn't work as desired so you bring it back to the computer and as soon as you give it usb power it locks up, long before you can even try to attach a USB console.

Not my experience (MicroPython v1.15 on a Raspberry Pico board from 2020) using Thonny. Note that main.py is loaded by the MicroPython interpreter after boot.py and long after initializing USB.

I did have trouble with reconnecting using MS Windows 10, but that's a Windows USB driver thing. No problems on Linux (Ubuntu 18.4).

Back in my XDA developer days I think the preferred terms were soft-brick (that can be recovered by reflashing the device) versus hard-brick (that puts the device in an unrecoverable state)

Reply on news.ycombinator.com