I have been in the embedded domain for many years. I really like the approach taken by the team here. Particularly since this team is really well-versed in developing virtual machines and programming languages. But I am very much biased in their favor.
Embedded development is tricky, and anything that can help improve the productivity is useful.
The problem is that there have been many, many attempts at doing this exact same thing over the years. And they all have to fight the same fight: to get some serious traction for their particular approach.
Back in the 00's, Sentilla did a Java VM for the MSP430. This got a lot of traction - they even
had James Gosling himself vouch for the project.
More recently, Electric Imp and Particle.io have taken similar approaches, but with other languages.
Micropython and a variety of mini-JS engines are also around. Espruino, Tessel.io, and many more.
In a technical sense, running a virtual machine on a microcontroller is a really good way to go. You remove a lot of low-level friction that you otherwise have to deal with. And you get a lot of things almost for free, such as Over-The-Air (OTA) updates, and more control over security.
But when you get down to actually doing the work, you frequently end up wanting to have all that low-level access, even if you have to endure a bit of pain. Sometimes you don't even want to have an operating system with a hardware abstraction layer. You kinda want the bare metal.
So Toit are in a tricky situation. They may have a really good product. But they will have to get some serious traction. Developing a rock solid programming language and virtual machine is hard. Really hard. But it is way easier than to get that sweet, sweet traction.
It is the same problem all over again. embedded is tricky because you want to do too much with too little.
Then every time there's advancements in what you have available, people add all the niceties back. And at this point it is not embedded anymore. It's just a low power full device. Just like java for the MSP430 (like anyone would spend $7.99 per chip for a TV remote with 2week batteries, instead of $0.004 and 2+month)
True embedded development usually doesn't even have room for a watchdog timer. let alone virtualization and memory protection.
This is not new. This is not embedded. This is just the usual cycle of hardware generation changing and people in academia ivory tower (or worse, google solid gold tower) having nicer toys than everyone else.
Well put. This is a natural, expected and in many ways welcomed development in the cycle, but it’s not so much ‘embedded’ (in the sense you and I think of it) as ‘processors in this range are now computers, not microcontrollers.’
An ESP32 (and oh man they’re great) is more powerful than a mid-late 90s desktop, but power isn’t what separates a computer from a microcontroller. It’s the abstraction compared to the bare metal control.
(To be clear, the project in the post is very much embedded, but programs running on a vm written in a high level interpreted(ish) language are not so much.)
embedded is a term that means your code is closer to the discrete component analogy as possible, with all the same design and testing expected from the electrical design.
If you want to add modern language niceties to it, fine, But I would say that anything that brings in the "app" concept, and specially installation and fleet management, the better term is microcontrollers.
> True embedded development usually doesn't even have room for a watchdog timer.
A watchdog timer is often a piece of functionality internal to an MCU. https://microchipdeveloper.com/8bit:wdt The majority of embedded development does use watchdog timers, at many levels.
It seems there are some conflicting ideas about what "embedded" means. For the conventional definition, if it's in a single function box that doesn't look like a computer, it's embedded. Even 20-30 years ago your laser printer might have had more CPU and memory than the computer connected to it, and it was considered embedded. ATMs are embedded too. MS sells "embedded" versions of Windows.
Maybe the industry would benefit from some more fine grained terminology here, perhaps call the small stuff MCU embedded?
You are correct: I think the definition has been fixed in time even as the underlying meaning changed: I've programmed "embedded systems" that were based on x64-class processors.
But that's not the important part. I think one major problem is that the term "embedded" puts a lot of engineers into a frame of mind that rejects programming in anything high-level. We have done lots of projects where something like MicroPython would have been perfect, but every time I try to sell something like that, I get a bunch of excuses that really aren't grounded in any concrete objection and we go right back to twiddling bits in C.
Usually that is the same crowd that even refuses C99, or any other compiled language in alternative to C, even though there are vendors still in business selling such compilers.
I'm hoping someone brings WASM to MCUs with a HAL interface like WASI does for OS platform functionality. As far as I can tell, the byte code is simple and easy to write an interpreter for, with a lot of practically useful features like static memory blocks declared ahead of time that make it conducive to MCUs. It should even be possible to write test harnesses with simulators for each architecture that gives a precise prediction for how many cycles a given block of WASM will take in an interpreter so that timing for interrupt handlers, tasks, etc can all be worked out in simulation without even touching the hardware.
If a given block of WASM isn't performant enough in the interpreter, then drop it to compiled code and expose it to the rest of the WASM - at least then only a small fraction of your code requires a painful firmware upgrade, the rest can be updated in a user defined section of ROM. It would be great to have a compiler/linker combo that could use annotations to configure which parts of the firmware should be compiled and which should be interpreted. With inlining or even just AST substitution (replace global vars with register access), it should provide all of the low level access necessary while still allowing for high level Arduiono style libraries
Having messed with some WASM code, I would say that the byte code is NOT easy to write an interpreter for due to the (IMO insane) way blocks work. Blocks are nested but the start/end tags need to be matched up in order to determine where control flow goes - unlike jump instructions, the block tags don’t come with offsets built in. This means a fully-fledged interpreter needs to maintain a stack of blocks and (for efficiency) pre-scan each function to identify the block boundaries. That’s going to hurt performance a lot and take up valuable memory on a microcontroller.
A modified WASM with explicit jumps and less “magic” behavior would be great. Perhaps a transpiler could generate such a “interpreter-friendly” pseudo-WASM to be loaded on the microcontroller.
(FWIW, even though WASM supports static data blocks, it also has provisions for dynamic allocation, and most WASM programs over-allocate their static blocks to make room for a C stack. So, in practice, making WASM work for microcontrollers and static data would also mean new languages or compilers that are much more conservative with memory use.)
Having written an interpreter for Wasm (Wasm3), you're right, it's not an ideal format for direct interpretation. Wasm3 does a transcoding pass first to optimize for speed, but we still have it running on some pretty constrained devices.
The blocks-with-return-values WASM uses are quite conducive to static analysis, so it's a rather sensible choice for a general purpose VM. It's essentially a different form of SSA which dispenses with the unintuitive phi-function syntax. Obviously, for actual execution, one might want a lightweight pre-processing step introducing actual jump targets.
One problem with embedded is how much variation there is across the board.
Articles like this hide this complexity by talking about "microcontrollers", but behind that innocent facade hide utterly different beasts like the Atmega (of Arduino fame), MSP430, PIC, SH4, and anything Cortex-M3-based, just to cite a few.
It's not just about the generic memory and compute constraints of the genre as a whole, but adapting to the specifics of each platform. Solved the platform/tooling for the ESP32? Great, but that doesn't help my STM32-based project.
To make a crude analogy: the familiar "PC" architectures are pretty consolidated (x86, x86-64, or arm32(Thumb), arm64), but they're like the primate clade compared to the microcontroller "animals" that range from the carpenter bee through the sponge.
Correct. Yet, it 'would be nice' if there were some toolchain that ran on all of those. Arduino environment is the closest thing today, I think. For what it is, it's not bad.
Embedded development is tricky, and anything that can help improve the productivity is useful.
The problem is that there have been many, many attempts at doing this exact same thing over the years. And they all have to fight the same fight: to get some serious traction for their particular approach.
Back in the 00's, Sentilla did a Java VM for the MSP430. This got a lot of traction - they even had James Gosling himself vouch for the project.
More recently, Electric Imp and Particle.io have taken similar approaches, but with other languages.
Micropython and a variety of mini-JS engines are also around. Espruino, Tessel.io, and many more.
In a technical sense, running a virtual machine on a microcontroller is a really good way to go. You remove a lot of low-level friction that you otherwise have to deal with. And you get a lot of things almost for free, such as Over-The-Air (OTA) updates, and more control over security.
But when you get down to actually doing the work, you frequently end up wanting to have all that low-level access, even if you have to endure a bit of pain. Sometimes you don't even want to have an operating system with a hardware abstraction layer. You kinda want the bare metal.
So Toit are in a tricky situation. They may have a really good product. But they will have to get some serious traction. Developing a rock solid programming language and virtual machine is hard. Really hard. But it is way easier than to get that sweet, sweet traction.