Cheap microcontroller for JavaScript or fast interpreter.

[qqclient]

you may try the project names Espruino, which utilizes ESP32 to implement javascript engine parsing js.

[qqclient]

how about Espurino?
it is a project that implements a interpreter on some MCUs such as ESP32,ESP8266 and stm32 etc.

[Fire Doger]

For similar processing (sound reactive RGB) I used C# and win forms.

Autogain, FFT, binning etc was done with simple functions using exactly uint32, 16, etc.. to be able to directly copy it to MCU.
result graphs was done on a canvas pixel by pixel.

It wasn't pretty but in a day I could fast experiment with code and adjust real-time the coefficients with sliders and view the result.

[bson]

Obviously, any interpreter for a dynamically typed language with managed memory is going to be orders of magnitude slower than a language like C/C++ that's designed to be statically typed and analyzed (more so C++) at compile time, but on a fast modern processor it can still be fast enough.  Just probably not for any sort of DSP applications, but it's not beyond the realm of possibility with a 400MHz CM7.  However, this assumes it doesn't do things like garbage collect at the wrong time, and doesn't expect the interpreter to run out of RAM.

[zapta]

Have you tried to ask chatgpt to translate it for you?  You can give it as many hint as you need, and then review the code and tweak.

May be a time saver.

[Georgy.Moshkin]

Have you tried to ask chatgpt to translate it for you?  You can give it as many hint as you need, and then review the code and tweak.

Instead, I ask it to find errors in my translation. It has spotted type casting and signed/unsigned problems several times.
Translation from C to JavaScript itself is very easy for me.
I do things like this:

Code: [Select]

// JavaScript:
maxIndHistory.splice(0,1); // shift
maxIndHistory.push(curSpectrumMaxInd); // store

// C:
memmove(&maxIndHistory[0],
&maxIndHistory[1],
sizeof(maxIndHistory)-sizeof(maxIndHistory[0])); // <--- shift
maxIndHistory[HISTORY_SIZE-1]=curSpectrumMaxInd; // <--- store

Problems often emerge from things like this:

Code: [Select]

// JavaScript arm_sqrt_q31() "simulation"
deviation=Math.round(Math.sqrt((deviation/2)/0x7FFFFFFF)*0x7FFFFFFF);
deviation=deviation/32768/16; // /32768 - convert to normal sqrt output /16 to scale into 0.255 range

// C:
deviation = deviation >> 1;
arm_sqrt_q31((q31_t)deviation,(q31_t *) &deviation);
deviation = deviation >> 19; // SHR 15+4 /32768 / 16
I need to maintain this stuff. Plus, I have a separate MATLAB-like script to calculate some coefficients. I'm in the process of eliminating this stuff. Will take some time, but it's worth it.

[Georgy.Moshkin]

Here is proof of concept of my DIY data visualization.
STM32 C code: macros DBG() passes variable name, size and data over serial connection to HTML web page
HTML+Javascript: using Web Serial API to receive commands sent by STM32 and dynamically create canvases to display data.
I think it's already better than STM32CubeMonitor
I just put DBG_1D() for any array and instantly see how it updates in Realtime in my web browser.
It would be perfect if everything can be done using single DBG(), but I haven't figured how to distinguish between variables/1d/2d arrays using plain C macros. That's why there are three macros DBG, DBG_1D and DBG_2D. As you can see, I made DBG_MAX() to implement scaling. The same way graph colors may be directly controlled from STM32 application. Any suggestions how to make it better?

[shabaz]

It's possible to do things pretty much like that with zero (or almost zero) code, using (say) Kst.
All you need to do is log your serial data (if your serial console software supports that). Kst will act on file changes and plot in real-time.

I've tried doing it in Python in the past too, and it's possible to send the configuration over serial too. I chose to send out JSON from the microcontroller (not really a serial streaming protocol! there will be better options), and then the Python code self-creates charts according to what's coming over the JSON-over-serial (say, writing the following over the UART: {“temperature”: 21.7, “sound”: 45} {“sound”: 47} {“sound”: 44} {“temperature”: 21.5, “sound”:43} and so on).
Screenshot example below in case it gives you ideas.

Sometimes it's easier to do something custom for the task-at-hand, for instance using WebSerial and JavaScript as you have done, although just a personal preference, I don't do anything except simple displaying of values etc with JavaScript, I'd rather do any data work with Python or Matlab etc.

[Georgy.Moshkin]

Just for the completeness:

The Microvium JavaScript engine for microcontrollers takes less than 16 kB of ROM and 64 bytes of RAM per VM while idle, making it possibly the smallest JavaScript engine to date with more language features than engines 4x its size.

I haven't tried it, but I liked the idea:

A foundational principle in Microvium is the ability to the snapshot the state of the virtual machine so that it can be restored and resumed later in another environment.

https://coder-mike.com/blog/2022/06/11/microvium-is-very-small/
https://microvium.com/getting-started/

[Doctorandus_P]

I'm surprised OP responds to his own tread half a year later...

I'm with bson. Develop the algorithms in C / C++ and run, test and debug them on PC hardware. Only in the last stages of the design, run them on a uC.

C++ has evolved a lot in the last 10+ years. New constructs, better optimizations, more modern methods for code design. from "auto" to constexpr and other stuff. I you have not closely at C++ lately, you really have to put in some effort to get up to speed, both with learning the new stuff, and also for shedding the old crud and habits. I'm guessing that half of C++ simply never should be used. It's only there because legacy code must be supported.

Also, with compartmentalizing your code in separate files, and paralleling the make process (with a -j12 or -j96 if you have that many cores on your PC) a build can be quite quick. (of course still depending on code size and such).

[tggzzz]

I'm guessing that half of C++ simply never should be used. It's only there because legacy code must be supported.

Probably. Unfortunately different people choose different subsets.

Having to be backward compatible limits the opportunities for clean language design and hence clean code design. Sometimes, as with COBOL, it is better to start afresh wherever possible.

It is quite entertaining/sad that people often say you shouldn't teach students old processors, but should use modern processors such as ARMs - and in the next breath insist that an old language should be used. Oh well.

[Georgy.Moshkin]

I'm surprised OP responds to his own tread half a year later...

with a useful idea of transferring VM state. I never thought about it this way, and it may spark some more ideas

[radiolistener]

But why not?  JavaScript uses IEEE double precision FP values for everything, and C perfectly handles those. It's also very easy to read and write JSON from C.

I just don't understand the problem here.

Just try translating this simple C code to JavaScript and you'll quickly see the challenges of float64 precision in JS. It should produce exactly the same result.

Code: [Select]

double v = sqrt(2);
printf("%.17g\n", v);

 


Another major issue in JavaScript is its handling of integers. I once built a calculator that needed to support int32, uint32, int64, and uint64 types, and I initially underestimated how problematic this would be. JavaScript’s Number type can’t accurately represent 64-bit integers, and even 32-bit operations can behave unexpectedly. In the end, I had to abandon standard numeric types and switch to BigInt for arbitrary-precision arithmetic - but while it solves the accuracy problem, it's far less convenient to work with.

That experience really made me appreciate how convenient working with int and float types is in C. You don't usually notice it in day-to-day coding, but C’s strong and explicit type system makes handling numeric data much more easy, predictable and manageable - especially compared to JavaScript, where the lack of strict typing and uniform Number type leads to subtle bugs and kludges.

[brucehoult]

But why not?  JavaScript uses IEEE double precision FP values for everything, and C perfectly handles those. It's also very easy to read and write JSON from C.

I just don't understand the problem here.

Just try translating this simple C code to JavaScript and you'll quickly see the challenges of float64 precision in JS. It should produce exactly the same result.

Code: [Select]

double v = sqrt(2);
printf("%.17g\n", v);

 

Not sure what you're trying to get at here.

Code: [Select]

Mac-mini:programs bruce$ cat foo.c
#include <stdio.h>
#include <math.h>

int main(){
  printf("Hello World! %.17g\n", sqrt(2));
  return 0;
}

Mac-mini:programs bruce$ gcc -O foo.c -o foo
Mac-mini:programs bruce$ ./foo
Hello World! 1.4142135623730951
Mac-mini:programs bruce$ python3 
Python 3.13.3 (main, Apr  8 2025, 13:54:08) [Clang 16.0.0 (clang-1600.0.26.6)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 2**(1/2)
1.4142135623730951
>>>
Mac-mini:programs bruce$ node
Welcome to Node.js v23.11.0.
Type ".help" for more information.
> 2**0.5
1.4142135623730951
>

Exactly the same from C, Python, and JavaScript. I don't see how it could be otherwise.

Another major issue in JavaScript is its handling of integers. I once built a calculator that needed to support int32, uint32, int64, and uint64 types, and I initially underestimated how problematic this would be. JavaScript’s Number type can’t accurately represent 64-bit integers

Correct.  JavaScript stores all numbers as double, which exactly represents and calculates with all integers up to and including ±2^53.

and even 32-bit operations can behave unexpectedly.

Like what? 32 bit integer operations are exact in double, you just have to make sure to mod values by 2^32 from time to time, or truncate fractional values if you're doing division.

Convincing a JavaScript JIT that your values are integers and to use your CPU's integer instructions instead of floating point is of course a lot of fun, but that's a speed optimisation not a correctness thing.

[radiolistener]

Exactly the same from C, Python, and JavaScript. I don't see how it could be otherwise.

This is actually not what I asked for, I asked for formatting with specific precision. Your code for js doesn't have precision specifier.

Well, try to do the same for let say "%.10g" and "%.20g"

And then try to translate this one:

Code: [Select]

printf("%+.4f\n", 15.0/123.0);


[radiolistener]

Like what? 32 bit integer operations are exact in double, you just have to make sure to mod values by 2^32 from time to time, or truncate fractional values if you're doing division.

Convincing a JavaScript JIT that your values are integers and to use your CPU's integer instructions instead of floating point is of course a lot of fun, but that's a speed optimisation not a correctness thing.

significant challenges arise once you start dealing with signed integers and need to accurately emulate overflow behavior, sign extension, and wrapping semantics to precisely match the behavior of native int32 or uint32 types. Ensuring this correctness in JavaScript requires extra care and often manual handling, since the language’s numeric model doesn’t natively enforce these integer semantics. So while JIT optimizations for integer operations improve performance, the real complexity lies in faithfully reproducing the exact integer behaviors, especially around overflows and sign handling.

In other words, when you simply need to perform basic calculations, JavaScript handles numbers reasonably well. However, once you impose strict requirements for precise handling across the full range of values and all possible operations, significant challenges arise. These issues tend to surface repeatedly and unexpectedly - much like a swarm of cockroaches emerging from a closet, making reliable, high-precision numeric programming in JavaScript quite difficult.

There is also a significant lack of native support for error-free calculations with 64-bit integer values which is usually present in C.

[zapta]

> Like what? 32 bit integer operations are exact in double, you just have to make sure to mod values by 2^32 from time to time, or truncate fractional values if you're doing division.

If what you care is correctness, you can abstract it with JS classes, int32, int64, etc.

https://chatgpt.com/share/68412f51-f62c-8000-a6b3-f71e3bf279bb

[westfw]

I'm guessing that half of C++ simply never should be used. It's only there because legacy code must be supported.

A lot of C++ seems to be added at being able to make the STL very ... flexible.
Looking at STL source code is almost like looking at another language.

[tggzzz]

I'm guessing that half of C++ simply never should be used. It's only there because legacy code must be supported.

A lot of C++ seems to be added at being able to make the STL very ... flexible.
Looking at STL source code is almost like looking at another language.

What's debugging like?

Bear in mind that the STL is a Turing-complete language "hidden" inside C++. Some valid conforming C++ programs can never complete compilation - because they cause the compiler to emit the sequence of prime numbers during compilation!

"Hidden" is stunningly accurate: the STL language creators refused to believe they had created a Turing-complete language, until Erwin Unruh rubbed their noses in it[1]! If the language designers can't understand their own language, what hope do mere mortals have? Is that a sound basis for an engineering endeavour?

[1] https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP

[brucehoult]

I'm guessing that half of C++ simply never should be used. It's only there because legacy code must be supported.

A lot of C++ seems to be added at being able to make the STL very ... flexible.
Looking at STL source code is almost like looking at another language.

What's debugging like?

Bear in mind that the STL is a Turing-complete language "hidden" inside C++

You are confusing a language feature, templates, and a library, STL, developed by Stepanov at HP (and published as open source software by HP in 1994) that makes use of templates (and other) language features.

STL hasn't existed since the C++98 standard when equivalent functionality was absorbed into the C++ standard library as "standard containers" and "standard algorithms".

[tggzzz]

I'm guessing that half of C++ simply never should be used. It's only there because legacy code must be supported.

A lot of C++ seems to be added at being able to make the STL very ... flexible.
Looking at STL source code is almost like looking at another language.

What's debugging like?

Bear in mind that the STL is a Turing-complete language "hidden" inside C++

You are confusing a language feature, templates, and a library, STL, developed by Stepanov at HP (and published as open source software by HP in 1994) that makes use of templates (and other) language features.

STL hasn't existed since the C++98 standard when equivalent functionality was absorbed into the C++ standard library as "standard containers" and "standard algorithms".

Whoops!

I gave up on using C/C++ professionally just before that, partly because of the template mess, partly because of the "cast away constness" irreconcilable dilemma, and partly because for non-embedded applications there were other better (fast, productive, expressive) languages.

[radiolistener]

If what you care is correctness, you can abstract it with JS classes, int32, int64, etc.

Yes, it's true that you can implement abstractions like int32, int64, uint32 and uint64, and others using JavaScript tools to emulate correct numeric behavior. For example I used BigInt to bypass these js issues, it is much slower and more complex to handle, but it give you predictable behavior. However, this is not what most developers expect from a programming language when implementing algorithms. The goal is to focus on the logic itself - not to spend time fighting around language limitations and kludges, dealing with edge cases and building virtual machines just to get reliable number handling. A language should provide robust native support for such fundamental types, especially when correctness and predictability are critical.

JavaScript is quite convenient for quickly building utilities with a graphical interface that run on any machine with a web browser. However, as a programming language, it is just a piece of shit, particularly when it comes to code analysis and implementing logic that requires precise numerical computations. Its dynamic typing and loosely defined numeric behavior often make it more of an obstacle than a tool in such contexts.

However, there are currently no real alternatives that offer the same ease and portability for writing browser-based applications, so we often have to work within the limitations of what's available. This is precisely why tools like Emscripten have emerged - essentially implementing a virtual machine in JavaScript that allows code written in more robust, strongly typed languages to run in the browser while leveraging the GUI capabilities available through JavaScript.


Returning to the topic of using JavaScript on microcontrollers - it's far from an ideal choice. MCU environments lack web-browsers, and the language itself is highly resource-intensive, both in terms of runtime and memory footprint. Given the limited resources available on typical microcontrollers, JavaScript is generally unsuitable for such low-level, performance-constrained applications.

As for the challenges of porting code from other languages to JavaScript, one of the most notable issues is the lack of proper numeric formatting support. What is straightforward and reliable in other languages often becomes a source of frustration in JavaScript, requiring workarounds, kludges and unreliable hacks to achieve the same level of precision and control.

[zapta]

> However, as a programming language, it is just a piece of shit

Crap languages rule the world. Take Python for example. If JavaScript would support operator overloading, using the numeric abstract classes would be more straight forward, allowing statements such as a = b + c.

BTW, Python is available also for microcontrollers https://en.wikipedia.org/wiki/MicroPython

[Doctorandus_P]

I have once experimented a bit with MicroPython. I flashed it on a Black Pill (STM32F411) after soldering on an external flash chip. After that, when plugged in to your PC via USB it acts as an external drive. I think I loaded a python script directly from that thing in a text editor, and it automatically executes the script when it's saved. But I'm not sure. It also had options to set a sort of batch file, that runs at power up.

I found the whole thing a bit intriguing, but I don't really know what to do with microPython on a microcontroller. I rather use C / C++ myself. One thing for which micropython may be interesting is to see the results of direct register manipulation, and to learn how the STM32 works from that.Via the REPL you can read from and write to registers, and there is some way to get symbolic register names, so you don't have to look up the binary addresses yourself. But the syntax is quite weird. MicroPython has also versions for a bunch of other platforms.

On a sidenote:
How good is AI these days to translate sourcecode form one computer language to another? It probably is not perfect, but I guess it will save you some time if it works reasonably well.

[tggzzz]

On a sidenote:
How good is AI these days to translate sourcecode form one computer language to another? It probably is not perfect, but I guess it will save you some time if it works reasonably well.

If the result doesn't have to work properly (i.e. only reasonably well), then I can generate it very quickly without LLMs.