JavaScript for Microcontrollers | Hacker News Reader

JavaScript for Microcontrollers

github.com

59 pointsselvan76 comments

A few years ago, I was astounded to find that I can write modern C++ code for arduino. It’s pretty great; rvalue && parameters, classes, even STL string manipulation all works perfectly. C++11 and later added all kinds of useful syntax for writing fast, small code. In particular, I don’t need nearly as much preprocessor macro crap, because it’s easy to make the compiler compute constants, even when those constants are produced by manipulating STL data structures.

Compiling expressive syntax through a powerful optimizing compiler to produce binaries run by microcontrollers is really sweet. Definitely the way to go, if you want to get the most functionality from limited hardware, without going all the way to assembly.

I guess JavaScript could be good for people who want to do very simple things, and then invest lots of time fighting limitations as their ambitions grow, rather than learning something useful. Like people do with Excel.

Which brings me to my next question: why not take it to the limit, and make microcontrollers programmable purely in Excel macros? That would be maximally accessible. Lots of people know Excel and can’t get enough pain.

Your sour attitude feels displeasing to read.

You probably haven't written modern JS. Since ~2016 (ES6) the language is basically completely different and really concise now; consider ES5:

  function increment() {
    var out = []

    for (let i of [1,2,3,4,5]) {
      out.push(i + 1)
    }

    return out
  }

vs ES6:

  const increment = () => [1,2,3,4,5].map(i => i + 1)

etc. Most people's experience with JS/TS has simply been before ES6 (which had massive problems, like `var` and `this` scoping etc.), it's really nice nowadays.

To go maximum pedant here, I want to say that you're somewhat conflating syntax improvements for stylistic shifts. Pre ES6 JS still allows for FP programming, so a more fair approximation of the Pre-ES6 code would be...

  var increment = [1, 2, 3, 4, 5].map( function(num){ return num + 1 } )

The two big syntactic wins of modern JS are let/const over the filth that was var and the convenience of arrow functions over anonymous function literals.

To go maximum pedant, your `increment` is an array instead of a function which returns that array:

    var increment = function() {
        return [1,2,3,4,5].map(function(num) {
             return num + 1;
        });
    };

Moreover, modern JS is not merely convenient syntactic sugar over old JS. Let/const have different scopes, arrow functions have no bindable context.

You also now have classes, proxies, async/await, generators, destructuring, default/rest/spread parameters, ...

Add typing via jsdocs or TypeScript and - like the parent comment said - "it's really nice".

Often people mistake JS for a mere DOM manipulation language and think of

    document.getElementById('myDiv').innerHTML = 'Hello World';

instead of what it has become today.

I still hate it though for sorting arrays with only number types lexically:

    [1,2,10,20].sort(); //[1,10,2,20]

Well, not if you know that .sort(); is meant to accept a custom sort function too [1,2,10,20].sort((a,b)=>b-a)) // 1, 2, 10, 20

The issue here is that for some reason I often struggle to remember which function sorts in ascending order [(b-a) or (a-b)].

In fact, your example suffers from the same problem: It sorts in descending order (20,10,2,1) instead of ascending (1,2,10,20).

Telling JS to use a TypedArray [Int8,...,BigInt64] instead can solve this without remembering and providing your own comparator:

    Float64Array.from([1,2,10,20]).sort(); //[1,2,10,20]

I don't really understand your point of disagreement. I never claimed let/const/Arrow Functions were syntactic sugar, just that they were improved syntax. I don't see our two arguments as mutually exclusive, because I feel syntax can imply the addition of new features, as long as those features are directly tied to that syntax (by this definition, I would argue that JS classes are actually syntactic sugar, but that's a whole other can of worms).

I will concede that I failed to write a function definition, thanks for catching that. I guess I unintentionally refactored the outer function away because development brain took over? Sloppy on my part, regardless.

I would argue that extending "improved syntax" beyond readability to carry "addition of new features" blurs the lines between syntax and semantics.

The point was that modern JS is more convenient to use: Const/let, arrows, classes, proxies, async/await, generators, destructuring, default/rest/spread parameters, etc.

Even if you discard const/let/arrows as merely syntactic improvements (which they are not), you should not ignore the others - unless of course they are all syntactic improvements with added features at which point "syntax" lost its "meaning".

The problem with JS and large applications was never the verbosity but that you can do horribly mistakes without getting any feedback until runtime since your mistakes are valid JS, they just mean something else than what you meant.

I.e. due to the lack of typing this will fly just fine:

const calculateInterestingNumber = () <calculations goes here>;

let twiceAsInterestingNumber = 2 * calculateInterestingNumber; // (ooops, missing parenthesis)

... until runtime.

This was just the silliest contrived example.

In practice this - as you are fixing someone else's code and misplace/forget a set of parenthesis - ends up taking 30 minutes to figure out.

Use typescript then

That's exactly what we do.

Many forget that modern microcontrollers are much more powerfull than 16 bit home computers, and that is where I started with C++, had C, Turbo Pascal, Turbo Basic, QuickBasic, Clipper, Lisp, Prolog, Forth,.... at my disposal as well.

Sometimes reading comments about what microcontrollers aren't able to do in 2020 looks like cargo cult of people lacking the experience of how it was like to code with 640 KB.

> Compiling expressive syntax through a powerful optimizing compiler to produce binaries run by microcontrollers is really sweet. Definitely the way to go, if you want to get the most functionality from limited hardware, without going all the way to assembly.

I highlight that. In fact, Rust is another kid on the block that is very promising for embedding.

In the other hand, sorry but I simply don't get why JS for interactions on such highly constrained devices. Probably as you said, it's intended to do very simple things with less effort as possible.

Every time a thread like this comes up, I feel that I would like to read some comments that are not assertions on why JavaScript (or Python for that matter) is a bad idea to put on "everything".

If nothing else, it seems like a good idea to make microcontroller programming more accessible using one of the most used languages.

I'm not sure arguments regarding performance, or how readily available learning resources are for lower-level programming languages, are relevant here because those are likely not the concerns for anyone who wish to take advantage of frameworks like the one in question.

To many people the programming part is just a means to an end: for example, making LEDs blink for costumes. So why not celebrate when there are more accessible solutions available to them?

Making software development more accessible leads to more software. It doesn't necessarily lead to better software. I think this is the collective groan you hear.

Anybody can take garageband and slap some autotuned vocals on a track and make a song. That does not make the average person a skilled musician. Musicians that have taken the years of practice to get that tone just right on their cello are not going to have a lot of respect for someone that achieves it pushing some buttons on their midi keyboard.

You are probably right though. I don't know if it really matters how the sausage is made.

"Programming is too important to be left to the programmers."

I believe we owe the vitality of the software business to the fact that we never rationed, or maintained gatekeepers for, software development.

Disclosure: I play the cello. The lesson from the music business is that the definition of a skilled musician is no consolation when someone lowers the barrier to entry with technology (electric guitar & bass, scratch turntable, sampling, PC based recording, autotune).

See also:

Espruino: https://www.espruino.com/

JerryScript: https://jerryscript.net/

Running javascript on microcontrollers is surprisingly popular. Personally I keep returning to C, but these frameworks can be nice when they "just work".

Does this framework support general-purpose SPI communication, or only SPI displays?

I am hesitant to use plain JS on web applications now that I've been using Typescript for so long. I would feel even more hesitant to write fast and loose JS on a microcontroller

Typescript compiles to js. Presumably you could have a typescript layer for this - but at that point it seems like your time would be better spent translating typescript to a compiled language than going ts -> js -> interpreter

Then use Microsoft's MakeCode instead.

https://makecode.com/language

“ The constraints of the target microcontroller may limit the number of language features that can be used in combination by a single application.”

Thats a pretty huge caveat.

I do not, and will not, fully understand the desire to put JavaScript or Python interpreters on a microcontroller.

Forty (40) years ago, children were writing assembly on home computers! No internet to run to for help, back then, but somehow, millions of kids learned how to do it.

Today, with all the resources available, assembly is "scary," and "too hard to teach."

I call BS on this notion. Complete BS.

JavaScript doesn't even really belong where it is on desktops and laptops. The very last place it belongs is on a constrained platform.

Was it really millions? I find that hard to believe. I was a kid at that time and was very into computers. I never truly learned assembly and I'm sure I knew more about it than anybody that I went to high school with.

I was in High School with 300 other kids and there were at least two dozen of us who at the very least toyed with assembly on either the TRS-80, a VIC-20 or an Apple II, and knew enough that we wanted to know more. I grew up in a farming community in Illinois.

I doubt that there were millions in any single country, but over the entire world, I would be very surprised if "millions" is not accurate. (Precision is another discussion)

I was like dexterdog, the only person in my school that could program. I toyed around with assembly and C and made some progress but nothing significant. I know people who went to other schools with a dozen or more kids toying around together, like you, and they made it a lot further during their school years, and this advantage has left them still very far ahead to this day, 30 years later.

People learn much faster and better in groups than as individuals.

I had a number of kids in my school (very few in my grade) who were into programming, but nobody was interested in assembly. This was the late 80s. We had an AP class which was not common at the time and I was able to skip intro comp sci in college because of it. Pascal was the main language.

An ESP32 can have 1 or 2 cores, running at 160+MHz. It has built in Wifi and Bluetooth, and usually 500KB and 4MB of Flash that programs can run out of.

IIRC, that compares reasonably well with a 486 or Pentium computer running a single application, especially when you realize it's not running a GUI. A decent amount of software of that era was inteprreted - that's when Javascript and Python first came into existence.

Run JavaScript on a 486 and tell me how it performs when compared to something written in any natively compiled language whatsoever.

Then tell me if you think any owner of a 486 would have tolerated that level of performance.

We would, because back then JavaScript already existed and I was using it in Netscape Navigator.

Worse, we even had interpreted Java applets, with the JIT a couple of years in the future to come.

All those were used for tiny of functionality in browsers and did not even remotely approach the performance and functionality of the real desktop applications.

You mean like Office dragging on a 486 because one just had 8 MB?

Imagine how that computer would run JavaScript.

Even today, JavaScript is 1/20th the speed of native code at best.

Imagine something dragging at 1/20th the speed of MS Office on a 486.

I don't need to imagine, I was at the university back then.

This makes no sense. I do not recall the amount of RAM I had on my 486DX50 but whatever version of office it had at the time ran just fine. JavaScript was not even born by then. But when first ever versions of JavaScript were released their execution speed were molasses comparatively to native applications. I know it first hand as I was developing native and web and in browser applications since 94 even before JavaScript (I used Netscape's server push functionality for that). When Java was released and until it matured to decent enough JIT it was the same slow resource hog (again know it first hand).

Born by when? When 486 was released?

Naturally not, however not everyone was wealthy to be buying last generation Pentiums.

I do not quite understand what you're trying to say here. Many are / were not wealthy to buy any computer at all back then. I was born long before 486.

My first computer was a Timex 2068, I was born long before IBM even cared about home computers, if you want to go down that route.

One reason JS makes sense (in; for example, robotics): For all of JS’ problems, it handles async wonderfully. I can think of plenty of actions in robotics that boil down to “do these 3 things concurrently and then do thing #4 when they all complete” and Promise.all or async/await are helpful constructs to have when designing those instructions. It won’t be as performant, but the developer won’t have to worry about polling or communicating across threads/processes

That’s not a knock against assembly, or to say that the same can’t be done in C with time and skill. But in many cases, compromising performance for developer efficiency is a good call.

If concurrency were so hard that switching away from some decent language to JAVASCRIPT seemed like a good idea, I would agree, but it isn't that hard. Not even close. Threads are a very well understood concept.

It's just that JavaScript has no threads, which is it's problem.

And nor do most microcontrollers, so perfect fit!

async has another benefit: the mcu can sleep while the program is waiting, which offers an easy way to write low-power systems.

Why not just use C++ and not sacrifice any performance at all? You say async so it might not be applicable, but C++ has a standard memory model you can rely on for consistency.

Why can't you just replicate these features in C? Surely await/promise libraries exist?

I don't get the impression from the linked website, that this is for beginners...

>>> Bring your existing experience with JavaScript, but be prepared to think about performance, code size, and memory use in a different way.

I think the use case is if your application would actually benefit from the Javascript language, either because of what it can do, or to make something readable and maintainable in a way that might be hard with raw assembly.

In a similar vein, I played with CircuitPython for a while, and went back to C for my microcontroller projects. My programs tend to feed data up to a desktop computer, typically into the loving arms of a Python program.

I got into computers almost exactly 40 years ago, and the earliest exposure of most kids to programming was in BASIC. I read a book on the Z80 microprocessor, and felt that I could have at least taken a crack at assembly, but didn't have access to a Z80 machine.

But if they where achieving back then what nowadays kids are achieving with python and js, they would be gods in that time.

I would be willing to bet that assembly wasn’t the first language you learned.

The first programming I did was as a kid when I taught myself basic on an apple II+ after I saw a joystick and a manual sitting next to my dad’s computer. ...it looked a bit like my Atari console and I was curious. (I too eventually wrote assembly - you had to in those days - but it wasn’t the introduction to programming for anyone I knew.)

This led to other things, including the robotics company I started, where we are, as I write this, running JS on an esp32 (among other things), hoping to inspire someone else to discover programming as I did - through play and fun.

To me, JS is kinda like basic was when I was a kid. ...the first step on a path that could surely include assembly, ML, distributed systems, robotics, computer vision, etc.

But what should step 1 be for kids today? I have a 6 year old, and all I know is she’s growing up in a different world than I did. ;-)

The first language I learned was machine code. Just saying. And I was in no way programmer. I was just a scientist trying to get some digestible data from the device used in my experiments. As the time went by I got Assembly, C, Turbo Pascal etc. I knew about basic but have never used it.

I first started programming when I taught myself at 3 years old digital logic. I started with just combinatorial logic (I was 3 after all!) but in one week I graduated to sequential logic.I still remember the spark of pride on father's eyes when I showed him the ALU I just created, he still told me to do better. Several ISA and micro-architecture later and half a dozen of languages created ( I remember fondly Beethoven,it was OO, this was before Simula) I started to get good at it. But then Gerda, my dear _Lehrerin_ had to go back to Germany (something about her father) and I had to start first grade so I set those juvenile games aside. I think they still somehow shaped the gentleman I am today.

Yours fondly. Oneupyou McGill

People put interpreters for popular languages into environments hoping to grow the population using that environment. It is an attempt to entice an audience of technically adept people easily, adding value to your environment.

Think about kids who are getting into programming through JavaScript because they have access to the dev environment without installing anything. Now those kids can work on building hardware as well using the same programming experience.

We aren't losing anything here.

> Forty (40) years ago, children were writing assembly on home computers

Last time I checked, the majority of those kids were using BASIC. Specifically: Commodore BASIC or QBasic (DOS).

And Javascript is the modern version of BASIC: widely supported, well integrated into all modern OSes (phone, tablet, laptop, desktop), and capable of doing all of the graphics that a modern nascent programmer wishes.

BASIC is closer to assembly than JavaScript, both in complexity and that you can't implement a JavaScript anywhere as simply as you can implement BASIC

Yes. And BASIC could sometimes be compiled to native code. JS is always interpreted.

C64 BASIC was explicitly interpreted.

I wasn't talking about BASIC, I was talking about assembly.

Assembly wasn't that hard on those old things, so why is so much time spent today shoehorning JavaScript into places it shouldn't go? Spend that effort on something useful, or at least something sane.

And I'm talking about BASIC, which spawned a generation of programmers. PIC-BASIC, QBasic, TI-83 BASIC, Commodore BASIC. That's how programmers got their start back in the 80s.

> Assembly wasn't that hard on those old things

Assembly is harder than BASIC, and its harder than Javascript.

You can go to any store and pick out a beginner Javascript book these days. But how many Assembly tutorials or books are there?

Back in the 80s, it was more about Commodore BASIC books being distributed with the Commodore itself: ftp://www.zimmers.net/pub/cbm/c64/manuals/C64_Users_Guide.pdf

Pre-internet, it was books like these that allowed programmers to learn and grow.

I was one of those kinds, JavaScript and Python are the modern version of the BASICs we had on those computers, that I learned before even bothering with hexdumps, monitors and Z80 code.

No way.

Python turned into an abominable hot mess over the years due to lack of direction, and nobody really wants to program in JavaScipt willingly. It's something we have to put up with.

Sadly, there is no equivalent to BASIC in 2020.

It is all a matter of which BASIC we are talking about.

I only programmed QBasic way back when, but most of them had built-in IDE's and graphics support out of the box, didn't they?

Imagine dumping webpack, DOM and CSS on an unsuspecting kid today. Or even virtualenv and pip.

I know I'd "nope" out of there as fast as I could if that was me in 2020.

Nope, unless you are calling GW-BASIC, or the 8 bit line numbered BASICs an IDE.

The power of fashion overcomes reason and feasibility.

> JavaScript doesn't even really belong where it is on desktops and laptops. The very last place it belongs is on a constrained platform

I'd love for you to back that up with some kind of logic.

The semantics are a mess on a fast machine (Wat), and it doesn't expose enough invariants nor control to be useful on a small machine.

What's the point in using a language which isn't quite sure what an integer is when you can just use C. It's not that hard.

The difficult part is all the crap in the toolchains not the code itself.

I can see how it's limited on an embedded device.

But C has way more "wat" in it than JS, in a sense. In JS when you make a wat you can generally debug it and fix it incredibly easily. In C when you wat, well, good luck.

A linter and Typescript and the fact that the "wat" stuff is actually almost always marginal and not commonly ran into in practice means you actually almost never are spending time on wat-ness at all in TS, where in C, a huge amount of time is spent there.

There's a vast gulf of productivity between TS and C (the former winning). TS is an incredibly smart choice for many things small and large. But yes, if you need a lot of low level hooks and incredible performance, don't use it.

Why not the best of both worlds? There are other compiled languages than C/C++. Many provide neatly the productivity of dynamic languages but with much better control. Rust & Nim both work well. Maybe Zig one day.

Rust is far slower as a developer to write (far more complex and verbose), Nim has orders of magnitude less ecosystem/docs/community (Rust has much less too), and both have far worse debugging tools, REPL, etc.

Valid points, and the REPL in JS/TS is handy. But it's worth pointing out that when/if a project outgrows JS, there are more options than just C/C++. The smaller community/ecosystem doesn't matter nearly as much in embedded, at least for libraries. I've found all the Nim libraries I've needed or wrapped C SDK ones, and the debugger is the standard C one. Rust is similar, and more productive than C for many people once you get familiar with it. Though yes, you've got to be willing to figure out things in both. Overall it's good to see more options.

I learned programming using python. And I agree completely.

Not sure if sarcasm, but writing assembly is complete shite to be honest, even on bare metal. Simple things suddenly take significant time and you probably create a worse result than modern compilers, even on more arcane platforms. Maybe it is useful for an interrupt routine to put some data in a data buffer.

Maybe interpreters are too much for µC, I think the most painful disadvantage of C is string manipulation and trends show a preference for human readable protocols for serial communication. For prototyping even JS might have use case though.

I would argue that assembly is not so bad if you take the time to learn it. A lot of the "high level" things that people attribute to compiled languages exist in assembly. And I also understand why it seems so unapproachable and why people don't want to learn it.

If the bar for entry into assembly programming in 1980 was so low that a child could do it, why are we thinking that we should lower the bar further today? Spend that effort on something which will actually help someone, rather than putting JavaScript on a microcontroller.

Microcomputers from the 80s booted to a BASIC interpreter REPL. There's no reason why a similar constrained system from the current era couldn't just boot to a JS REPL.

And yes, if you wanted to do anything really significant, you needed to learn assembly. But frankly most did not bother.

You're right. We wouldn't want to lower the bar to programming too much. Just imagine if the wrong sorts of people took advantage of the advancing technology and lower barrier of entry to substantially improve their lives! We really should be using assembly for web development so we know that only the truly dedicated and those committed to the craft can participate in this career.

That is not the point I'm trying to make at all. You conjured my talking point out of thin air and then attributed it to me. I should have expected this...

I'm not gatekeeping. I'm saying that we spend a lot of effort to lower the bar to software development when it is already very low. It is certainly already low enough that anyone can become a software developer. I would like to see that effort used for something more productive.

Reply on news.ycombinator.com