Kaluma Puts JavaScript On The RP2040

RP2040 picture on left by Phiarc, CC BY-SA 4.0, via Wikimedia

With a simple firmware update, Kaluma puts a lightweight JavaScript runtime on the Raspberry Pi Pico (which uses the RP2040 microcontroller), providing handy modules for file systems, graphics, networking, and more. Code for a simple LED blink can then look like:

// index.js
const led = 25;
pinMode(led, OUTPUT);
setInterval(() => {
digitalToggle(led);
}, 1000);

Development can then be done using tools that are very familiar to JavaScript developers, such as npm and flashing new code to a USB-connected Pico with the (Node.js-based) Kaluma command-line interface. Take a look at the GitHub repository for the project, or browse some of the projects made with Kaluma.

Much like with MicroPython, there’s value to be had in putting implementations of high-level languages on microcontrollers. Each new language opens embedded programming to a whole new group of coders. But it’s not just languages making their way to the RP2040. Wonderful projects such as emulating the ZX Spectrum on an RP2040 also happen.

Thanks to [Shri Hari Ram] for the tip!

38 thoughts on “Kaluma Puts JavaScript On The RP2040

  1. I once looked into java / javascript shortly and discovered it does not support unsigned variables. I’d say that makes it pretty much unusable for microcontroller development, but you will probably be able to blink a led with it.

    1. From a practical point of view this is kind’a irrelevant. Javascript has 32-bit signed and unsigned shifts, which is basically the only place you might have issues with unsigned values.
      The Moddable Javascript SDK actually rocks on ESP32 and RP2040.

  2. Honestly this really triggers my autism haha, JavaScript is neat as a learning language (because it’s extremely forgiving) so i do get the thought process behind it, but stuff like NodeJS already seems incredibly wrong to me & this is taking that a few steps further.

    JavaScript was created as pretty much “a front-end language”, literally to do basic form validation & drop down menus etc, it’s not meant for server side and certainly not meant to be running on chips. I don’t mean to be rude to the people that made or suggested this but just don’t do this, please.

      1. Real language? I ‘ve spent many years of programming from old gw basic and C64 Simon’s basic 😁 days. All the memories of hours and days of sad and fun with machine code (from hard times of Z80 coding and assembly to the modern ones) makes me familiar to different languages (less or more or even much more 😉) like fortran, c, pascal, …, python and javascript. The wise one is the one who peeks the right tool for the job. Javascript is a real language and Node.js is great for back-end if you know it enough. But all is up to you to step to the right path armed with the best weapons or the wrong one naked!

    1. > I don’t mean to be rude to the people that made or suggested this but just don’t do this, please.

      I’ll be rude: Don’t listen to this donkey. You don’t have to do avoid doing something just because some luddite on a tech forum tells you not to.

      If you want to run javascript on your RP2040 go right ahead and do it! You don’t need to feel bad for using what you’re familiar with. If it works it works. If it doesn’t, feel free to try to make it work. Either way, hopefully you have fun in the process!

  3. Not sure why all the javascript hate. Being able to run some primative javascript on a microcontroller with wifi could open the door to using the microcontroller for web automation. For example, a lot of auth mechanisms for API access need javascript so subsequent calls could be made (JWT for example) and so I think it definitely has its place in this space.

    1. Running javascript on this this thing doesn’t provide any web automation benefit. You’re not going to be able to run code intended for Node.js. There’s no meaningful compatibility.

      The only real advantage of javascript is having a REPL and the language being simpler/more forgiving.

      The JWST doesn’t use javascript for anything related to the web or internet at all. It just happened that javascript was a popular fad in the 90’s and got integrated as a scripting language. At least it’s better than if they had chosen Lua.

        1. Nasa has their own separate command and control infrastructure and protocols for issuing commands and uploading files to spacecraft (javascript scripts and otherwise).

          It’s not like you connect to the JWST with a webpage.

    2. Making JWT calls from python is super easy, and we have micropython for that already. I personally see no benefit from having JS on the microcontroller.

      Now, I’m more on the “meh” side of this development. Not because having JS on microcontrollers is inherently bad. But JS has an ecosystem of bloat and JS developers are used by the V8 and other engines solve performance for them, and this version of JS won’t do that. So I think this will end up in the same pile as NodeMCU, which is lua on microcontrollers, and as soon as you try to do anything serious in it, it crashes&burns. Which is why everyone is using micropython/circuitpython instead, which seems to be a lot more stable and has a lot more libraries to grab for off-the-shelve problems.

    3. Just so we’re clear, if that was partially directed at me, i most certainly don’t hate JavaScript (I have like 15 years of web development under my belt & use it a lot) but i strongly feel like it doesn’t belong on server side or hardware because it was made for basic front-end stuffs, not back-end.

      The fact that JavaScript is extremely forgiving is both its strength (in the case of learning programming & quick results) and its weakness (in the case of production environment)

      To give a very simplified example, in most languages an error will just lead to a crash telling you (roughly) where to look for the error, in JavaScript it first tries to go “hmm, i think they meant to do X?” which tends to be correct 75% of the time, that is actually REALLY cool and what makes it so easy to learn, but it’s also slow and somewhat dangerous, because in most cases it wont even tell you that this happened & now every time the code runs it has to go through that process for each issue/typo it encounters, so your code is slower.

      And then when the javascript interpreter gets updated (which is not often, but does happen from time to time) it could suddenly decide “hmm, actually they might have meant to do Y instead of X?” and now your code you haven’t looked at in years suddenly breaks from some update that shouldn’t even be causing any issues & you’ll waste a lot of time looking at completely different parts because you’re not aware of this ‘hidden’ error in the code.

      Now you might wanna respond with something like “i don’t care about if’s and buts” and that’s a totally valid response in some contexts, but this is where the autism kicks in for a lot of us, we do care about them 🤣 and as it turns out, most companies care about them a lot too, caring about if’s and but’s plays a big part in getting the ‘senior’ sicker and the bigger paychecks 😉

      Oh and JWST tokens are just JSON & javascript requests don’t need javascript on the other end to work, so while i totally get that you we’re just looking for an example use case, that isn’t one.

  4. There is one advantage to using VM based languages on a microcontroller that hasn’t been mentioned yet – and that’s dynamic loading/relocatable code. I’m not very familiar with the RP2040 architecture, but I know dynamic loading from e.g. an SD card on the ESP32 using native code is unreasonably difficult, and becomes trivially easy with a byte code interpreter.

  5. I see a huge opportunity in education applications here.
    No compilation needed, just flash your bundle. There’s even a browser based solution which makes it even more easy to use in school class environments.

    And stop moaning about EcmaScript, it’s as good as any other language for learning the basics. Remember: Real programmers use butterflies (https://xkcd.com/378/).

  6. >digitalToggle

    so we get the best of Arduino and Javascript in one :o)
    On one hand this will result in absolute worst quality code imaginable, on the other will be even easier to program than Arduino. JS is modern computer lingua franca and Im all for it.

  7. Oh god. Why are there developers so insistent on shoehorning this kludge of an excuse of a programming language into every possible orifice 🤦
    Seemingly simple tasks like compiling a super basic mobile app make a Core i9 CPU and NVMe SSDs look slow because every last action is friggin JavaScript these days…

  8. I suppose this port makes sense to someone :) . But when you already have microPython, circuitPython, C, and assembly…. Well, I personally don’t need anything else. Sockets is supported for any web application in Python or C already if you have Pico Ws. I’ll use JavaScript in a browser as needed, just not here. Just me though.

    1. You don’t have to use it :-). But after using micropython for quite a while, I find it actually really nice to use a good Javascript on RP2040 (not the Kaluma one). JS is actually well specified and the Moddable implementation supports all of the relevant JS standards, plus the performance is really good. Being able to use async stuff and multiple concurrent workers means way fewer lines of code and way more readable than using arduino or such.

  9. When you are trying to reach a wider audience and want to keep things easier for people, JavaScript is the way to go, you can do things in JS faster and quicker than other languages and the real idiots are those who don’t understand that JS is just a front end that gets compiled into machine code and run on the microcontroller just like C# or whatever you code with. Shame that Arduino is still stuck in its ways, it would make learning and developing simple programs much easier and faster if the end user is using something that they have already learned without having to expend hours on learning syntax and debugging and asking repeatedly about why errors exist in a convoluted low level language approach.

    1. Bingo. All those kids to whom you have to figure out how to teach coding, this is a huge push in one direction. Now you can make a website, code a simple game, and work on a robot without having to learn 3 languages.

  10. I never got Kaluma working on Pico 2 W. Kaluma is severely experimental and doesn’t provide basic features like WiFi access point mode. You basically have to wait for someone to help you do the tough task of writing a NodeJS module and practically the ready to use ones are very very limited.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.