phoddie
Posts: 7
Joined: Sat Feb 20, 2021 2:33 am

JavaScript on Pico

Mon Feb 22, 2021 9:42 pm

I wanted to let everyone know that we are working to bring JavaScript to the Pico using the XS JavaScript engine in the Moddable SDK. We've already got a lot of the language working:
  • The same modern standard JavaScript language used on the web (BigInt, private fields, RegExp, eval, Promises, JSON, WeakRef, etc)
  • Source level debugging
  • Precompiled and preloaded scripts (near instant start-up)
  • Automatic elimination of unused engine features (reduces flash storage needed)
Right now about all you can do is blink an LED... but we are actively bringing-up the rest of the runtime. If you want to help with the porting effort or suggest features, join the discussion.

If you have questions or ideas for the port, just reply and I'll do my best to answer them here.

Thanks!

phoddie
Posts: 7
Joined: Sat Feb 20, 2021 2:33 am

Re: JavaScript on Pico

Thu Mar 04, 2021 6:10 pm

We've been making great progress on JavaScript for the Pico. We've been working on the fundamental IO APIs. We recently got I2C working. I implemented a version of the bus scan example from the Pico SDK. It is crazy fast -- a full scan of the bus takes about 1/10 of a second. That's much faster than an ESP32 (which takes about 1 second for each devices... for about 2 minute for a single bus scan....).

I thought it would be fun to try a real-timer I2C bus scanner. That's really useful for debugging project wiring. It works really well. The notifications print out even before I can get the wires fully connected to the breadboard!

Here's a a video with 3 I2C devices on the same bus: https://www.youtube.com/watch?v=UdXWbFtpgKo

The code roughly follows the model of the bus_scan.c example.

Code: Select all

import Timer from "timer";
import I2C from "pins/i2c";

const addresses = new Uint8Array(128);

function isReserved(address) {
	return (0 == (address & 0x78)) || ((address & 0x78) == 0x78);
}

function scan() {
	for (let address = 0x00; address <= 0x7F; address++) {
		if (isReserved(address))
			continue;

		const i2c = new I2C({address, timeout: 50});
		let found = undefined !== i2c.read(1);
		i2c.close();

		if (found && !addresses[address])
			trace(`Found 0x${address.toString(16).padStart(2, "0")}\n`);
		else if (!found && addresses[address])
			trace(`Lost 0x${address.toString(16).padStart(2, "0")}\n`);

		addresses[address] = found;
	}

	Timer.set(scan);
}

trace("Scanning I2C...\n");
scan();

phoddie
Posts: 7
Joined: Sat Feb 20, 2021 2:33 am

Re: JavaScript on Pico

Sat Mar 06, 2021 5:14 pm

I was curious to see how quickly JavaScript can start running on the Pico.

A common knock on using scripts on embedded is that it really slows down start-up time because you have to load and compile the scripts each time. The XS JavaScript engine has a preload feature for embedded devices like the Pico. It lets you compile and link during the build on your computer.

There's a few steps to start up. Here's what I found:
  • The time before the project main() is called. I'm ignoring that since it is inescapable
  • stdio_init_all - this is common to most projects. It runs in about 202 microseconds
  • Creating the JavaScript visual machine. This can be time consuming because it has to create all the JavaScript built in objects (Object, Date, Promise, etc). It takes just 718 microseconds (under one millisecond) because the built-in objects are created when building the firmware on the computer
  • Running the first JavaScript byte code. This requires loading a module, creating a stack frame, and starting the byte code engine. It takes about 1700 microseconds. I think this could be even faster.
So the total time, from entering main to running JavaScript is under 3 ms! And that number doesn't increase much as scripts grow, because preload does the work to build and run scripts on your computer.

Anyway... pretty amazing that the Pico running at a modest 133 MHz can get over 400 JavaScript virtual machines running a second. And that's just using one core. ;)

fanoush
Posts: 841
Joined: Mon Feb 27, 2012 2:37 pm

Re: JavaScript on Pico

Sat Mar 06, 2021 7:25 pm

Just wondering, does it have interactive console on the device like micropython? can I add or edit javascript code directly on the device? You describe lt more like compiled language where you build everything on main computer.

bgolab
Posts: 375
Joined: Sat Jan 30, 2021 12:59 pm
Location: Krakow, PL

Re: JavaScript on Pico

Sun Mar 07, 2021 8:05 am

There is very popular JS implementation for Microcontrolers:
https://www.espruino.com/

I used to play with espruino for sometime using STM32 boards.

Are going to release something similar?

I believe someone is going to port the espruino to RPI PICO:
http://forum.espruino.com/conversations/359042/

fivdi
Posts: 464
Joined: Sun Sep 23, 2012 8:09 pm
Contact: Website

Re: JavaScript on Pico

Sun Mar 07, 2021 9:57 am

fanoush wrote:
Sat Mar 06, 2021 7:25 pm
Just wondering, does it have interactive console on the device like micropython? can I add or edit javascript code directly on the device? You describe lt more like compiled language where you build everything on main computer.

To minimize the use of RAM and ROM and to operate efficiently in memory-constrained environments the XS JavaScript engine uses pre-compilation. See also How does the Moddable SDK make JavaScript run well on constrained devices? in the FAQ.

For debugging there's a full featured debugger called xsbug which can be seen in action in this video. To the best of my knowledge, due to pre-compilation, there is no interactive console like MicroPython and JavaScript code can't be edited directly on the device.

fivdi
Posts: 464
Joined: Sun Sep 23, 2012 8:09 pm
Contact: Website

Re: JavaScript on Pico

Sun Mar 07, 2021 10:09 am

bgolab wrote:
Sun Mar 07, 2021 8:05 am
There is very popular JS implementation for Microcontrolers:
https://www.espruino.com/

I used to play with espruino for sometime using STM32 boards.

Are going to release something similar?

I believe someone is going to port the espruino to RPI PICO:
http://forum.espruino.com/conversations/359042/

One of the main differences between XS JavaScript and other implementation is the level of support for ECMAScript standards.See also How is XS different than other JavaScript engines for embedded? in the FAQ.

bgolab
Posts: 375
Joined: Sat Jan 30, 2021 12:59 pm
Location: Krakow, PL

Re: JavaScript on Pico

Sun Mar 07, 2021 10:20 am

As I am not JS expert (only accidental espruino user) so I wonder what is the practical implication (in other words the benefit) of moving toward your implementation - I mean MCU world.

I use espruino sometimes when I want to use different programming paradigm - when I want to use event based approach in some rare cases (mostly when dealing with GSM modems in the past).

Sorry for the ignorance...

fanoush
Posts: 841
Joined: Mon Feb 27, 2012 2:37 pm

Re: JavaScript on Pico

Sun Mar 07, 2021 12:45 pm

fivdi wrote:
Sun Mar 07, 2021 9:57 am
To the best of my knowledge, due to pre-compilation, there is no interactive console like MicroPython and JavaScript code can't be edited directly on the device.
Then I think one advantage of interpreted language on embedded device is gone. So now with XS engine JavaScript is made similar to Java or C#. But if one cares about memory and speed why not write in something that compiles to native code directly like C/C++ (Arduino) or Rust?

The point of interpreters (like Micropython or Espruino or previously BASIC) is simplicity and flexibility. You can write and change code directly on the device to prototype quickly. Also e.g. with Espruino it allows you neat things like script one device from another (i.e. pass strings of javascript and evaluate remotely) over bluetooth. Then to read sensor or control something you don't need to invent custom communication protocol, javascript code is the protocol - you just pass "LED1.set()" or "analogRead(D1)" or call some method remotely. And it also works from web browser via web bluetooth - so with simple web page (even running on your phone) you can control your device or see its state - all just with few lines of js code on both sides. ​Also debugging (=fixing bugs) can be fun with this, I see bug in my function so I redefine it on the fly and continue and next time the updated one is called.

So I think that making JavaScript compiled is missing the original idea a bit.

However I still see the point of XS - let people who currently code in javascript/typescript nodejs to use exactly the same approach (or even same libraries) on embedded. Well if it works then why not. The more ways are there the better.

ndabas
Posts: 20
Joined: Sat Jan 23, 2021 11:54 am

Re: JavaScript on Pico

Sun Mar 07, 2021 1:08 pm

bgolab wrote:
Sun Mar 07, 2021 8:05 am
There is very popular JS implementation for Microcontrolers:
https://www.espruino.com/

I used to play with espruino for sometime using STM32 boards.

Are going to release something similar?

I believe someone is going to port the espruino to RPI PICO:
http://forum.espruino.com/conversations/359042/
Yes, that someone is me -- I'm working on the Espruino RP2 port. I'll post here and on the Espruino forum when I have something working.

bgolab
Posts: 375
Joined: Sat Jan 30, 2021 12:59 pm
Location: Krakow, PL

Re: JavaScript on Pico

Sun Mar 07, 2021 1:23 pm

fanoush wrote:
Sun Mar 07, 2021 12:45 pm
fivdi wrote:
Sun Mar 07, 2021 9:57 am
To the best of my knowledge, due to pre-compilation, there is no interactive console like MicroPython and JavaScript code can't be edited directly on the device.
Then I think one advantage of interpreted language on embedded device is gone. So now with XS engine JavaScript is made similar to Java or C#. But if one cares about memory and speed why not write in something that compiles to native code directly like C/C++ (Arduino) or Rust?

The point of interpreters (like Micropython or Espruino or previously BASIC) is simplicity and flexibility. You can write and change code directly on the device to prototype quickly. Also e.g. with Espruino it allows you neat things like script one device from another (i.e. pass strings of javascript and evaluate remotely) over bluetooth. Then to read sensor or control something you don't need to invent custom communication protocol, javascript code is the protocol - you just pass "LED1.set()" or "analogRead(D1)" or call some method remotely. And it also works from web browser via web bluetooth - so with simple web page (even running on your phone) you can control your device or see its state - all just with few lines of js code on both sides. ​Also debugging (=fixing bugs) can be fun with this, I see bug in my function so I redefine it on the fly and continue and next time the updated one is called.

So I think that making JavaScript compiled is missing the original idea a bit.
Yes, definitelly agree. The mentioned above features of the Espruino interpreter made me use it for a few platforms (micro:bit and other nrf based board, etc). Ability to send a command to interpret it on a remote system gives extra flexibility sometimes.

fivdi
Posts: 464
Joined: Sun Sep 23, 2012 8:09 pm
Contact: Website

Re: JavaScript on Pico

Sun Mar 07, 2021 2:06 pm

bgolab wrote:
Sun Mar 07, 2021 10:20 am
As I am not JS expert (only accidental espruino user) so I wonder what is the practical implication (in other words the benefit) of moving toward your implementation - I mean MCU world.

I use espruino sometimes when I want to use different programming paradigm - when I want to use event based approach in some rare cases (mostly when dealing with GSM modems in the past).

Sorry for the ignorance...

I'm not affiliated with Moddable so phoddie can probably provide a much better answer to this question than I can. I have used XS and the Moddable SDK in the past on ESP32 boards. At the time I also considered using Espruino. What I can say is why I chose XS rather than Espruino.

What I liked about XS was the the level of standards compliance, the performance and that I was able to get it to work on the first try in a reasonable amount of time. When it comes to standards compliance, XS compares very well with JavaScriptCore (WebKit/Safari), SpiderMonkey (Firefox) and V8 (Chrome). See here.

What I liked about Espruino was that it's easy to get it up and running. However, Espruino made me nervous as it did things I didn't expet it to do. As an example, it handles the keywords const and let differently to the way I expect them to be handled.

This is what Espruino does:

Code: Select all

 ____                 _ 
|  __|___ ___ ___ _ _|_|___ ___ 
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v08.189 (c) 2019 G.Williams

Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate

>    
>
>const c = 1;
=1
>c = 2;
=2
>c
=2
>
>
>
>let l = 1;
=1
>let l = "Hello, World!";
="Hello, World!"
>l
="Hello, World!"
>

This is what I expect:

Code: Select all

Welcome to Node.js v15.5.1.
Type ".help" for more information.
> const c = 1;
undefined
> c = 2;
Uncaught TypeError: Assignment to constant variable.
> c
1
> 
> 
> 
> let l = 1;
undefined
> let l = "Hello, World!";
Uncaught SyntaxError: Identifier 'l' has already been declared
> l
1
> 

In the end, I chose not to use Espruino because I couldn't make assumptions about how it functioned, assumptions that I thought I should be able to make.

fivdi
Posts: 464
Joined: Sun Sep 23, 2012 8:09 pm
Contact: Website

Re: JavaScript on Pico

Sun Mar 07, 2021 2:30 pm

fanoush wrote:
fivdi wrote:
Sun Mar 07, 2021 9:57 am
To the best of my knowledge, due to pre-compilation, there is no interactive console like MicroPython and JavaScript code can't be edited directly on the device.
Then I think one advantage of interpreted language on embedded device is gone. So now with XS engine JavaScript is made similar to Java or C#. But if one cares about memory and speed why not write in something that compiles to native code directly like C/C++ (Arduino) or Rust?

The point of interpreters (like Micropython or Espruino or previously BASIC) is simplicity and flexibility. You can write and change code directly on the device to prototype quickly. Also e.g. with Espruino it allows you neat things like script one device from another (i.e. pass strings of javascript and evaluate remotely) over bluetooth. Then to read sensor or control something you don't need to invent custom communication protocol, javascript code is the protocol - you just pass "LED1.set()" or "analogRead(D1)" or call some method remotely. And it also works from web browser via web bluetooth - so with simple web page (even running on your phone) you can control your device or see its state - all just with few lines of js code on both sides. ​Also debugging (=fixing bugs) can be fun with this, I see bug in my function so I redefine it on the fly and continue and next time the updated one is called.

So I think that making JavaScript compiled is missing the original idea a bit.

However I still see the point of XS - let people who currently code in javascript/typescript nodejs to use exactly the same approach (or even same libraries) on embedded. Well if it works then why not. The more ways are there the better.

I can understand these arguments. If the goal is to manufacture (potentially many) devices at as low a cost as possible the savings that can be made by not having an interpreter will outweigh the advantages in many use-cases.

hippy
Posts: 10955
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: JavaScript on Pico

Sun Mar 07, 2021 3:01 pm

phoddie wrote:
Mon Feb 22, 2021 9:42 pm
I wanted to let everyone know that we are working to bring JavaScript to the Pico using the XS JavaScript engine in the Moddable SDK.
Just to note that "The instructions for getting started are in the repository" at the end of that page leads to "404 Not Found".

phoddie
Posts: 7
Joined: Sat Feb 20, 2021 2:33 am

Re: JavaScript on Pico

Sun Mar 07, 2021 4:45 pm

There's a lot of good points and questions here. Let me try to address them.

First, The Getting Started link in the blog post was incorrect. Here's the correct link:

https://github.com/Moddable-OpenSource/ ... es/pico.md

Once big question is whether a REPL is supported for interactive scripting. The short answer is "yes, there's a REPL!". The longer answer addresses some other questions along the way.

The XS JavaScript engine implements over 99.5% of the current JavaScript standard. That's better than many web browsers. It does that on MCUs like the Pico. To do that as efficiently as possible, XS implements pre-compiling and pre-linking which allows JavaScript to use less memory, launch nearly instantly, and run faster. These are all great. ;) The comments which note that this is similar to how you work with Java or C++ are correct.

Part of the JavaScript language standard is the eval function which allows JavaScript code to compile and run other JavaScript code. As a conforming implementation of the JavaScript language standard, XS implements eval. We (Moddable) don't use it as much because it is less efficient. For that reason, we even encourage developers to think twice about using it. But it is there and it works.

A REPL is "just" an application that reads terminal input, calls eval, and outputs the result to the terminal. There is a REPL app in the Moddable SDK examples. It is bare bones, but it works on many platforms and devices. The REPL is written in JavaScript so you can adapt it pretty easily to work however you like.

We hadn't made bringing up the REPL example on Pico a priority. We've been focused on fundamental IO. Since this discussion thread raised the topic, I did some work yesterday and this morning to get the REPL working on Pico. Here's a little demo video.

https://www.youtube.com/watch?v=7aF5OCi0ZRw

I need to do some clean up before committing it so everyone can try. After that, I'lll try to make a video that does a bit more.

Embedded development is often about making tradeoffs. With XS, you can choose whether you want to allow interactive use of JavaScript in a given project. If you don't need it, you can save the flash space for eval. If you can precompile and/or prelink your scripts, they run faster and use less memory.

As for the questions about why JavaScript with XS is interesting on Pico? It is, by far, the most standard compliant JavaScript engine for embedded. One reason developer like JavaScript is that it is available and behaves consistently in many environment s. With XS on Pico JavaScript can be used as a traditional REPL for interactive development while its preload feature allows for even more efficient execution on MCUs.

fanoush
Posts: 841
Joined: Mon Feb 27, 2012 2:37 pm

Re: JavaScript on Pico

Sun Mar 07, 2021 9:08 pm

phoddie wrote:
Sun Mar 07, 2021 4:45 pm
Part of the JavaScript language standard is the eval function which allows JavaScript code to compile and run other JavaScript code. As a conforming implementation of the JavaScript language standard, XS implements eval. We (Moddable) don't use it as much because it is less efficient. For that reason, we even encourage developers to think twice about using it. But it is there and it works.

A REPL is "just" an application that reads terminal input, calls eval, and outputs the result to the terminal. There is a REPL app in the Moddable SDK examples. It is bare bones, but it works on many platforms and devices. The REPL is written in JavaScript so you can adapt it pretty easily to work however you like.
wow, sounds great, and the https://blog.moddable.com/blog/eval/ is pretty informative including some numbers - ~500K of code with features not stripped and REPL compiled. While Espruino fits even 256KB flash and 16K RAM of nrf51 (including native bluetooth stack and Espruino API on top of that) it is tight fit, 64K ram, 512K flash of nrf52832 is sweet spot. So even if Moddable may need even more resources, with flash and RAM size of Pico this may not be an issue, more compliant engine is definitely a big plus.

BTW the blog post mentioned one reason why REPL and parser is discouraged - parsed bytecode is stored in RAM, can't you write parsed bytecode to file/module stored in flash and then run it from there?

phoddie
Posts: 7
Joined: Sat Feb 20, 2021 2:33 am

Re: JavaScript on Pico

Wed Mar 10, 2021 4:52 am

fanoush wrote:
Sun Mar 07, 2021 9:08 pm
wow, sounds great, and the https://blog.moddable.com/blog/eval/ is pretty informative including some numbers - ~500K of code with features not stripped and REPL compiled.
Thanks! Of that ~500K total for ESP32, about 210K is ESP-IDF SDK that isn't part of the engine. The Espressif MCUs use the Xtensa instruction set which isn't particularly compact. The ARM Thumb code on Pico is smaller. It looks like the REPL binary is about 422 KB on Pico. That includes just about all of the latest JavaScript language specification (which has grown since the blog post about the REPL).
fanoush wrote:
Sun Mar 07, 2021 9:08 pm
While Espruino fits even 256KB flash and 16K RAM of nrf51 (including native bluetooth stack and Espruino API on top of that) it is tight fit, 64K ram, 512K flash of nrf52832 is sweet spot. So even if Moddable may need even more resources, with flash and RAM size of Pico this may not be an issue, more compliant engine is definitely a big plus.
Using the strip feature, we run on similarly small devices. We demoed XS on a Silicon Labs MCU with 256K of flash and 32K of RAM for Ecma TC39 (JavaScript language committee). A lot of that RAM was empty. ;) That demo includes an animated display and a bunch of sensors. At that size, things get tight though. Being able to automatically strip unused features helps a lot. Still, the Pico really is in a sweet spot. Running XS there's plenty of flash and RAM free, so many projects don't need to worry about those resources.
fanoush wrote:
Sun Mar 07, 2021 9:08 pm
BTW the blog post mentioned one reason why REPL and parser is discouraged - parsed bytecode is stored in RAM, can't you write parsed bytecode to file/module stored in flash and then run it from there?
Yes, that would work. We haven't done that yet because we already have other good ways to get byte code into flash. In addition to being able to build JavaScript byte code into the firmware binary (like the REPL), we also can install precompiled JavaScript modules, called mods, into an existing firmware. Those are often just a few KB in size, so they install almost instantly. That's on our to-do list to get working on our Pico port.

I had hoped to get a Moddable SDK update up with REPL support by now. We ran into a hiccup updating to the March 4 Pico SDK, which delayed that plan.

WizIO
Posts: 105
Joined: Mon Feb 22, 2021 8:34 am
Location: Sofia
Contact: Website

Re: JavaScript on Pico

Mon Mar 15, 2021 9:12 am


niklauslee
Posts: 3
Joined: Fri Mar 26, 2021 4:05 am

Re: JavaScript on Pico

Fri Mar 26, 2021 4:16 am

I want to introduce Kaluma, an open-source JavaScript runtime for Raspberry Pi Pico. It provides JavaScript runtime as well as Web-based IDE for sharing modules. Currently in beta.1.

Here is the website:
https://kaluma.io

A blink example video:
https://youtu.be/F8wU4ZQuKkg

hippy
Posts: 10955
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: JavaScript on Pico

Fri Mar 26, 2021 3:03 pm

niklauslee wrote:
Fri Mar 26, 2021 4:16 am
I want to introduce Kaluma, an open-source JavaScript runtime for Raspberry Pi Pico. It provides JavaScript runtime as well as Web-based IDE for sharing modules.
Looks interesting but it appears one needs the Kaluma Agent to use the IDE and that's only available for Mac and Windows.

And when I do go to the IDE - https://kaluma.io/ide - using Chromium on my Pi ... "INTERNAL SERVER ERROR".

I tried "npm install -g @kaluma/cli" on my Pi and got permission errors, even when using 'sudo', therefore don't get the 'kaluma' CLI app.

I can access the REPL via 'minicom' but can't see how to get code into it when doing that as it seems to only accept YMODEM packets.

As useful as it seems to be, a little help, making it more usable and accessible, for Pi users would probably go a long way in attracting interest from the Pi-using community.

niklauslee
Posts: 3
Joined: Fri Mar 26, 2021 4:05 am

Re: JavaScript on Pico

Sun Mar 28, 2021 6:25 am

hippy wrote:
Fri Mar 26, 2021 3:03 pm
niklauslee wrote:
Fri Mar 26, 2021 4:16 am
I want to introduce Kaluma, an open-source JavaScript runtime for Raspberry Pi Pico. It provides JavaScript runtime as well as Web-based IDE for sharing modules.
Looks interesting but it appears one needs the Kaluma Agent to use the IDE and that's only available for Mac and Windows.

And when I do go to the IDE - https://kaluma.io/ide - using Chromium on my Pi ... "INTERNAL SERVER ERROR".

I tried "npm install -g @kaluma/cli" on my Pi and got permission errors, even when using 'sudo', therefore don't get the 'kaluma' CLI app.

I can access the REPL via 'minicom' but can't see how to get code into it when doing that as it seems to only accept YMODEM packets.

As useful as it seems to be, a little help, making it more usable and accessible, for Pi users would probably go a long way in attracting interest from the Pi-using community.
Thank you for your feedback.

Unfortunately Kaluma CLI and Agent are not support ARM machines including Pi and Apple M1 at this time. For Apple M1, Kaluma Agent can be used because it will be automatically translated by Rosetta 2, so no problem in Apple M1 for IDE with Agent.

We will try to resolve this issue as soon as possible.

niklauslee
Posts: 3
Joined: Fri Mar 26, 2021 4:05 am

Re: JavaScript on Pico

Sun Mar 28, 2021 6:40 am

hippy wrote:
Fri Mar 26, 2021 3:03 pm
niklauslee wrote:
Fri Mar 26, 2021 4:16 am
I want to introduce Kaluma, an open-source JavaScript runtime for Raspberry Pi Pico. It provides JavaScript runtime as well as Web-based IDE for sharing modules.
Looks interesting but it appears one needs the Kaluma Agent to use the IDE and that's only available for Mac and Windows.

And when I do go to the IDE - https://kaluma.io/ide - using Chromium on my Pi ... "INTERNAL SERVER ERROR".

I tried "npm install -g @kaluma/cli" on my Pi and got permission errors, even when using 'sudo', therefore don't get the 'kaluma' CLI app.

I can access the REPL via 'minicom' but can't see how to get code into it when doing that as it seems to only accept YMODEM packets.

As useful as it seems to be, a little help, making it more usable and accessible, for Pi users would probably go a long way in attracting interest from the Pi-using community.

Please try below for installing Kaluma CLI:

Code: Select all

$ sudo npm install -g @kaluma/cli --unsafe-perm --build-from-source

hippy
Posts: 10955
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: JavaScript on Pico

Sun Mar 28, 2021 10:58 am

niklauslee wrote:
Sun Mar 28, 2021 6:40 am
$ sudo npm install -g @kaluma/cli --unsafe-perm --build-from-source
Many thanks. That downloaded, built and installed it.

I now have my 'index.js' uploaded, my Pico LED flashing. Onwards and upwards!

dthacher
Posts: 151
Joined: Sun Jun 06, 2021 12:07 am

Re: JavaScript on Pico

Sun Aug 01, 2021 11:02 pm

I have a love/hate relationship with Javascript, Python, C#, etc. on MCU. There is a problem with expression to performance for interrupter based languages. Conceptually these languages are configuration/glue/front-end logic on controllers and not processing/computation logic. So this fits one common programming model just fine.

In this programming model you can bail out to native implementation in C/C++/ASM/etc, OS or hardware directly. So the performance aspect of this should be handled by one of these methods which should all be native. However the issue is this is not common. Sometimes they just let it ride or they run the Java model as I like to call it.

Java conceptually supports just about anything via modules/libraries. The modules are defined in interface then passed to platform implementation. Here native implementations should be called at runtime. This is one of the major approaches to high level languages and one of the major system definition approaches. It has a few pitfalls but is not commonly used completely.

CircuitPython is kind of implementing this and passing itself off as an operating system when in reality it is potentially a native/implementation interface. (To the programming it kind of is the same.) Call out directly to hardware via wrapper may not be supported, however hardware is usually limited in expression and capability.

Software is conceptually configuration. The underlying mode is what determines capability, performance and efficiency. The problem with interrupter systems is that they are generally poor in these areas. Assembly is technically interrupter compared to fixed hardware. The level of indirection creates waste.

The problem I see is these pretend to cut through these with magic. Conceptually if you could increase the expression, which I do not believe these languages do, you could increase efficiency without much effort. However commonly people want to keep the indirect logic due to convenience ,which has created a problem for these languages and these type of applications.

This is the future of programming that has never been solved. We know of a lot of untapped potential for both IO and computation exist in hardware. However the lack of flexibility is generally considered impractical. However software has other flavors which this does not apply too.

For example FPGA configuration. This has created an identity issue for software. Software now can control via bloated hardware more flexibility. However how exactly does one do this? My hope is the PIO will motivate people to look at this problem. So when considering Javascript on PICO, consider this.

One person said it well, hardware is just a library. Its like another processor, albeit less capable. This is what left these languages when they went into user land. They lost their soul, so to speak.


Just think that if I could tell the language to generate a hardware module for this block of code, function, or class. Have the entire implementation from a system level automatically generated. The hardware just exists. Or the compiler automatically finds the critical path and automates it. All from a high level language. No registers, pointers, timing, hardware, mess, etc. Just fricking magic that is not magic.

In reality it would be hardware inspired by a software interface. Compilers would become bloated, but oh well. This is why these language never really made sense to me. I have always loved C over Java due to the expression and freedom. Granted Java is less painful for some things, but darn it why is this not solved?

The best we can do not is pretend with multicore and algorithms. I know these are cheaper and more flexible. However they will eventually break down. We will need these for compilers and stuff. However this will hold for determinism and power consumption long term I am not sure. We also needed die shrinking so I guess all is not lost.

Although even this breaks down eventually. Time is money as they say and it only has to be good enough. So I don't know. I guess that is why the world is only so good and last for so long. Then again I am naive and other things. Somethings can never be but must be. Ironic but not to all.

Return to “General”