[HN Gopher] Kaluma: A Tiny JavaScript Runtime for RP2040 (Raspbe...
___________________________________________________________________
Kaluma: A Tiny JavaScript Runtime for RP2040 (Raspberry Pi Pico)
Author : tosh
Score : 67 points
Date : 2022-11-03 12:28 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| _ZeD_ wrote:
| how does it compares to micropython?
| moffkalast wrote:
| 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.
| chasd00 wrote:
| 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.
| Fatnino wrote:
| 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.
| oliwary wrote:
| 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)
| moffkalast wrote:
| 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.
| guenthert wrote:
| > 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.
| lasagna_coder wrote:
| 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.
| MuffinFlavored wrote:
| Does QuickJS https://bellard.org/quickjs/ not compile to/run on
| the RP2040?
| f_devd wrote:
| 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.
| Gravyness wrote:
| 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.
| lasagna_coder wrote:
| In short, in my experience it's good for toy projects but
| nothing "heavy"
| zachrip wrote:
| 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.
| eatonphil wrote:
| > 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/
| [deleted]
| incanus77 wrote:
| Related to Sprig, which is also on HN front page today:
|
| https://news.ycombinator.com/item?id=33451148
___________________________________________________________________
(page generated 2022-11-03 23:02 UTC)