A virtual machine for microcontrollers

https://blog.toit.io/why-doesnt-v8-fit-on-my-microcontroller-71dc6e2d8f5c

by tosh • 5 years ago

209 116 5 years ago

blog.toit.io

tosh• 5 years ago

An operating system is a collection of things that don’t fit into a language. There shouldn’t be one.

— Dan Ingalls

Found the quote in Byte Magazine Volume 06 Number 08 (Smalltalk) page 298

https://archive.org/details/byte-magazine-1981-08/page/n311/...

the_only_law• 5 years ago

The coupling between the smalltalk language and the environment has become mildly interesting to me recently. I’d tried to see if I could find any of the old Tektronix Smalltalk workstations recently, but sadly they will likely become just another very rare item in my list.

dahart4• 5 years ago

I feel like that quote might have been intriguing and made some sense on a home computer in 1981 but has no hope of being true today. Home computers in 1981 typically had no hard drives, ran exactly 1 process at a time, had no virtual memory, no internet connection, no GPU, etc., etc. Even the article you linked to is primarily saying that Smalltalk provides it’s own interface to things the OS also does, but is not even attempting to address concepts like multi-process, security, safety, resource contention & prioritization, and all the other things a modern OS does.

So what insight is this quote giving us today, does it still say something interesting, and is it still true in certain ways?

I don’t have a Smalltalk history or know much about projects like LispOS or Toit at all, but I do have a clear (to me) picture of what an OS does that is useful and should not be part of a programming language. One example of that is working on console games, for example Nintendo consoles, before they provided an OS. It was a nightmare because the game developer was on the hook for handling a very long list of abnormal system conditions. The certification process for a game on a Nintendo console required all developers to conform to standards that specified exactly what errors needed to be displayed under what circumstances. Game developers needed to handle cases where a player would accidentally bump open the CD tray or pull out a cartridge in the middle of a level load, or repeatedly yank and replace a controller cable, things like that. Think about how silly it is that every single game developer, thousands of them, had to - separately and individually - spend tons of time re-engineering the same solutions to these things that the console itself should have handled, things that a couple of people at Nintendo could have engineered once for everyone. Well, now they have an OS, and this is only one of the many reasons why. It might not be immediately apparent that Nintendo’s certification standards have any bearing or say on what a home computer should be like, but UX standards in system-wide error messages are important, designated responsibility for which process handles hardware errors and user notification are important, and making sure that efforts that have to be common to all programs are implemented in such a way that devs can’t mess them up and don’t need to reinvent the wheel are important.

CodeWriter232• 5 years ago

We had MP/M in 1979.

Koshkin• 5 years ago

No, an OS is what you see when you turn the damned thing on.

dragonwriter• 5 years ago

No, an OS is what you see when you turn the damned thing on.

Maybe, a bit, if it's a chatty OS, but, mostly, no, that’s a shell.

pjmlp8• 5 years ago

        **** COMMODORE 64 BASIC V2 ****
    
    64 K RAM SYSTEM 38911 BASIC BYTES FREE
    
    READY.

542458• 5 years ago

I feel like the title is a bit misleading - the article only mentions V8 once, and is actually about a (still interesting) new VM solution for ESP32s (and potentially others) that provides a more ergonomic development environment and simplifies things like having multiple programs running on the same MCU, OTA software update/install, and pseudo-isolating memory between programs. Easy/low-risk OTA updates in particular seems like it could be pretty killer to me - I know there are ways of doing it today, but the caveats are significant.

winter_squirrel• 5 years ago

From the title I would have expected this to be an article on V8, however there is barely any mention of it besides the title and the author saying he worked on it in the past. Instead, it seems to be an advertisement for a new language / VM, which makes it feel like a bait and switch. (even through the content itself is interesting)

irjustin• 5 years ago

Ugh this article was a total bait and switch.

Kasper Lund has a lot of my respect for work he did on V8 and Dart so I was hoping this was going to be super interesting article about trying to struggle to.... make V8 run on a specific microcontroller!

I think I feel more cheated because of his background and that it's highly featured on HNews.

tyingq4• 5 years ago

He does offer a few indirect references as to why running V8 on a microcontroller would suck. Like the section on polymorphic inline cache for method resolution.

zozbot2345• 5 years ago

Running V8 implies JIT and there is no JIT on most microcontrollers because they're based on Harvard architecture where no code can be written in data memory.

jeremyjh4• 5 years ago

So this is a shameless bit of marketing collateral but I also learned from it. I hadn't heard of Toit before.

sebe2• 5 years ago

The article does answer the question in the title. "Why doesn’t V8 fit on my microcontroller?"

"It is fast, but prohibitively expensive in terms of memory."

So there's no room for v8 on a $2 board, Toit vm and toit language have been designed from the ground up for the iot world.

Tidbit, Dart team did have an iot project called dartino, before flutter took over the dart world.

Anyway the article was posted on the toit website.

I've been following their progress via twitter. https://twitter.com/toitware https://twitter.com/toitlang

finnthehuman• 5 years ago

Ugh this article was a total bait and switch.

Yeah, as someone who works with microcontrollers professionally and would always love better tools to work with, this article didn't do much to sell me.

It is a nice bit of marketing in the way it positioned itself. I don't think I'd be able to articulate why I'm not rushing to use this without getting called an old fogey.

phoe-krk• 5 years ago

The article is not really about V8 not fitting on microcontrollers, but aside from that:

In a nutshell, the problem is that on microcontrollers everything is firmware that is compiled, linked, and deployed together using really old-fashioned tools. Changing anything means changing everything.

The author hasn't seemingly heard of http://www.ulisp.com/ which is small enough to fit within kilobytes of memory and at the same time featureful enough to drive complex microcontroller applications. At the same time, it has a normal REPL running on the microcontroller that is accessible from the outside and usable for Lisp-style interactive programming.

ashtonkem2• 5 years ago

Or circuit Python. I’m sure there are others too.

jeremyjh4• 5 years ago

There is also Micropython and there are a couple of javascriptish options as well. These are all leaky abstractions, none of these languages actually works exactly the same as the versions that run on full OSs with memory protection. As far as I know, none of it is actually used in industry and the workflow the author describes is the standard practice that is followed pretty much everywhere. Of course, Toit will also face an uphill battle to get any adoption in this market. I think they made a mistake using their own language instead of pretending it is Python or Javascript, even if this lets them shed a lot of baggage. Their platform is interesting though and does I think address some real challenges people would face when trying to get in-house IOT-type work done on ESP32.

petre2• 5 years ago

One can do more stuff with Tasmota and Berry language (which also looks like Python only with useful end statements) or Arduino, NodeMCU, MicroPython than what this platform offers at this time. I2C and SPI drivers, everybody has that. If one wants to do serious stuff they would use an appropriate RTOS and program it in C. MongooseOS does more than this if we're talking ESP32, also other devices, Javascript, C, C++, commercial support, cloud based OTA upgrades and integration with AWS, Azure, Google and IBM Watson IoT cloud services.

rattray2• 5 years ago

What are the shortcomings of Espruino and QuickJS?

http://www.espruino.com/

https://bellard.org/quickjs/

discreteevent• 5 years ago

I think they made a mistake using their own language

It might make adoption harder but I'm glad they did because it looks like a really nice language.

nesarkvechnep• 5 years ago

Or Nerves

jeremyjh4• 5 years ago

Nerves is based on the Buildroot distribution of Linux and will never be able to run on an ESP32 nor any other microcontroller that lacks MMU.

i_don_t_know• 5 years ago

They worked on a Smalltalk-inspired VM (OOVM) in the early 2000s. So I don’t think they claim that running a dynamic language interpreter is a new invention, ulisp, MicroPython, or otherwise.

I don’t know ulisp. I believe with MicroPython you basically have one monolithic Python application running in the interpreter on the device. I believe their claim is that their system enables you to have several applications run in their interpreter with reasonable isolation between them. So I think it’s more about having a single monolithic application vs a set of specialized applications / services that you can combine.

I believe their original system OOVM did allow for lisp-style (smalltalk-style) interactive development. I don’t know if their new system supports it too.

lebuffon• 5 years ago

There is a thing called a "tethered" or "umbilical" compiler in the Forth world where the target machine has nothing on it but a small comms program that is controlled by the IDE on the workstation. The IDE includes a way to kick off any piece of code interactively on the target from a command line but there is no actual REPL on the target machine, only the running code. This gives you a big IDE while running on a tiny target and reduces a lot of the crying shown in the cartoon. :-)

Is there something similar for other language environments?

buescher5• 5 years ago

I know of nothing exactly like that suitable for professional use.

There are ways to tether a microcontroller to a host IDE, like Linx for LabVIEW or the firmata protocol for lots of languages, but those methods don't let you go from running code on the workstation to running code on the target (easily) like I think you're describing. http://firmata.org/wiki/Main_Page

The Mathworks' Matlab and Simulink arduino stuff advertises some capability in that regard but I haven't seen it myself.

anthk3• 5 years ago

Also, Forth.

zozbot2345• 5 years ago

It's hard to substantively comment on this when the article is so tl;dr and written in wall-of-text style. What exactly is this proposed tech doing that can't be done by running a simple WASM interpreter on the bare metal? (JIT itself is generally off-limits on microcontrollers due to Harvard architecture, so interpreted code is the best case.)

deepzn2• 5 years ago

Can running WASM solve this?

deepzn2• 5 years ago

my bad, I didn't click on the article haha, but went straight to the comments.

vajrabum• 5 years ago

Kaspar Lund of V8 and Dart fame and Toit.io have brought an IOT platform to market based around a purpose designed dynamic language with a bytecode VM optimized for use in MCUs. That VM engine is hosted in FreeRTOS which together with the VM and a deployment API provide a reliable and crash resistant platform for deploying apps to your IOT fleet. In their words "deploy a long-lived Toit application on your device, as if it was a mobile app being installed on your smart phone." (https://docs.toit.io)

The server end of their platform provides the management and app deployment infrastructure. It's claimed that the RTOS and VM environment makes deployment reliable even in the presence of failing apps. And that one app on a IOT device will not prevent other apps from running compromise management or brick the device.

Toit.io, the company makes $$ by charging you .10/MB after the first 100MB/mo for use of their management and app deployment and you are left free to choose your own data platform. What I don't have feel for is what sort of utilization per device I can expect for the management and instrumentation traffic.

*Edit I dug around the website and the tooling including the language looks like it is mostly closed source.

leoedin• 5 years ago

It's a really great concept, and the embedded world is crying out for more solutions like this.

However, I'd be very, very hesitant to develop anything significant on this platform. At the very least I'd want to have a. the tooling to run unit tests / simulations of my programs on the PC before deploying and b. a clear migration path for if they went bust.

Their value add is the infrastructure around deployment, so why is their language closed source?

I really like the Balena.io approach - the whole platform is open, so if they do go bust you could run it yourself, but they provide real value in running the infrastructure - so it makes loads of sense to pay them.

twic• 5 years ago

So when Toit.io completes their incredible journey, rather than all their IoT devices being bricked, all their customers' IoT devices get bricked?

Depending on what "management" entails, that is. It might only mean that no more updates are possible!

scoutt6• 5 years ago

So basically this is an RTOS that runs an interpreter for a script(s) stored in flash. Correct? I didn't understand if this script is precompiled or not.

I'm sure that if you want to avoid

    uint8_t* ptr = 0x20000000;
    while(1) { *ptr = 0xFF; ptr++; }

you have to be interpreting something else that is not C.

But this is a very interesting project in the way it's presented. I did once something similar, running in parallel some sort of reduced LUA scripts.

Even though, after 20 years of working in embedded, my free and unsolicited advice would be this: if you want to learn embedded, no matter how hard you are trying to avoid it, you need to learn some low-level language like C (or Rust or whatever is fancy now).

Put your mind at ease and do the extra mile. At the end learning C is not that hard. And I suppose you are learning, because if you propose Toit in your workplace is because you don't know how to code anything better at the moment.

I don't want to hurt anyone's feelings or sound dismissive but... learn C (or anything low-level). The rest are just toys of the moment.

MayeulC2• 5 years ago

It really depends on your needs. Overkill microcontrollers aren't that expensive anymore. It's probably faster to prototype something with micropython than C. And I say that as a very proficient C developer.

On the other hand, C isn't hard to learn, since the language is so small. What's harder is to learn its pitfalls and the parts that are actually implementation-specific, and not specified.

I'd argue that learning some assembly (enough for a few toy projects) is more useful to understand the system. C is required if you want to make the most out of the hardware, at least for now.

scoutt6• 5 years ago

Overkill microcontrollers aren't that expensive anymore

I knew that this would be mentioned but I didn't want to write an extensive comment.

In many embedded markets, cents make the difference. Also, space constraints, power consumption, availability, etc., makes you reconsider overkillability/price relationship.

Someone will put a 16KB MSP430 in the BOM and there you go.

What I wouldn't buy is something like "hey, chips are cheaper, let use a prototyped javascript-system over a VM over an RTOS, just because".

What's harder is to learn its pitfalls and the parts that are actually implementation-specific

Yes. There are tradeoffs, like in everything in embedded.

It's probably faster to prototype something with micropython than C.

Personally I wouldn't know where to start with micropython.

pjmlp8• 5 years ago

Depending on the hardware, there are other languages available other than C.

For example I would rather use one of MikroElektronika Basic or Pascal compilers.

https://www.mikroe.com/

sebe2• 5 years ago

My understanding with toit vm you have can have multiple programmes running and if one crashes, the others continues. The vm, etc, allows live update and or to deploy something new.

If you're interested in hearing Kasper talk about toit, he did a long livestream the other day, the toit bit is at the 1hr 34min mark. https://youtu.be/k7YITNpvcaY?t=5640

rm445• 5 years ago

It's conceivable that microcontrollers with memory management units could become more commonplace. Your memory-trashing program could be restarted while the device keeps on doing other things, rather than the traditional bare-metal approach of having a watchdog restart the device.

the__alchemist• 5 years ago

The problem is that on microcontrollers everything is compiled, linked, and deployed together using really old-fashioned tools.

Not necessarily. There are modern and pleasant workflows using Rust.

This article is somewhat general. Ie, what is his intended use case? What is he building? Part of the beauty of embedded programming is you can avoid the complications of abstractions like virtual machines and operating systems, and the performance penalties that accompany them.

ashtonkem2• 5 years ago

Also, there are a variety of interpreted language environments for microcontrollers, including at least one in Python and one in lisp. Saying that microcontrollers must used statically compiled code is objectively incorrect.

Now most projects will use C due to space issues, but that’s a different argument.

sjburt• 5 years ago

Most projects use C because there was zero consideration for anything else. No embedded team sits down at the beginning of the project and says "should we use lisp?". It's just C. Or maybe "C, but use a C++ compiler with less UB".

markdeloura• 5 years ago

CircuitPython (derived from MicroPython) is objectively pretty excellent, and running on an increasing number of platforms. It's been a really great platform for education.

eqvinox3• 5 years ago

Aside from the massively misleading HN title, I don't see the point of replacing one machine language with another machine language. Even if the latter is a virtual machine language.

The microcontrollers you would use this on (i.e. not the absolute bottom end, which would be too slow for a VM) may not have a MMU, but they do have a MPU. That's enough to get process isolation. And implementing relocation to load an ELF image isn't rocket science.

Also, I'd like to point out the billions of embedded systems implementing safety critical functions like huge industrial robot controls, or the brakes in your car. They're all built (and certified) without a VM. As a matter of fact, the VM would probably make them fail certification, unless it is specified and verified itself to a very fine degree.

scoutt6• 5 years ago

billions of embedded systems implementing safety critical functions

I realize that there is a pattern: when high-level programmers talk about security and reliability, they basically mean "hackers breaking your system to steal your passwords". To the point that memory bugs = security vulnerabilities, and nothing else.

This, of course, has another meaning for embedded.

segfaultbuserr• 5 years ago

For application development, a memory corruption bug or a race condition is a safety issue that causes data corruption, and when the same corruption can be used to compromise the system, it's a security issue, as you said, often there's no point to distinguish them. In the embedded world, this distinction can be important. If a vendor says its microcontrollers have safety features, it means an elaborate system of watchdog timers, glitch-filtered inputs, and checksums. On the other hand, "a microcontroller with security features" means a crypto engine and secure key storage memory.

baybal2• 5 years ago

Indeed,

And VM == bye bye JTAG debugging, which makes it DOA for most developers past the Arduino level.

pjmlp8• 5 years ago

Thanks to MISRA-C and highly certification procedures.

Yet don't put too much trust into them.

https://hackaday.com/2016/10/24/toyotas-code-didnt-meet-stan...

eqvinox3• 5 years ago

I don't think there's all that many safety issues resulting from MISRA-C non-adherence that would be fixed by putting the entire thing on top of a VM. Also, I'd wager almost all issues that a VM can catch are also caught by using a safer language, e.g. Rust (without a VM.)

That said, the really bad safety issues in a car are probably on a much higher semantic level, i.e. "at X level of braking, do Y", which neither a VM nor a safer language like Rust could catch.

buescher5• 5 years ago

Apparently Toyota followed their own internal standards, the code met them, and no bug that would cause unintended acceleration has ever been found. I still wouldn't advocate for the problems that Barr and Koopman savaged as expert witnesses in the lawsuit, but Toyota was held to an extremely high standard in court.

https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... https://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRU...

hrishi• 5 years ago

I see how the title might mislead one into thinking that the author was about to outline his problems fitting V8 into a uC, but I don't understand the upset that he was successful.

If successful, the streaming service with lack of relocation should be a useful tool in the toolkit for working with microcontrollers. I don't see much use for it for me at the moment, but then I haven't used uLisp much either.

apaprocki• 5 years ago

... but if you do want a modern JS engine running on a microcontroller:

https://github.com/Moddable-OpenSource/moddable#moddable-sdk

kabdib• 5 years ago

Hmmm. If I chose a chip with the resources to run this Toit thing, I can reduce costs by switching to a cheaper, less powerful chip and writing native code. If I'm shipping several million of these, it's a no-brainer; it saves real money. In some products I've worked on, saving ten cents per board would be a big deal. Also note that you're paying more than money; fancier and more capable chips usually consume more power, so imagine some lively conversations with the industrial design folks about battery lifetime and size, too.

If you're using off-the-shelf consumer-y ESP things, you're likely insensitive to cost and you're probably paying for performance you don't need.

I last saw this technique (maybe 15 years ago) used by a super tiny .NET runtime environment intended for devices like smart watches; you wrote to "tiny" APIs, a tool did a bunch of reprocessing of your binary into smaller tables and whatnot, and poof, it would run on a watch. With all the GC and so forth going on, it's not something I'd want to write a whole embedded system in, though it was okay for applets.

I'm not oblivious to the security advantages of using a bytecode interpreter, but on a high-volume product you'd have to make a case for how important this kind of thing is.

buescher5• 5 years ago

ESP32 is extremely price competitive in its space. The use case is internet connected applications, which are going to need the kinds of resources Toit requires anyway.

What gets me is the implicit promotion of javascript as the gold standard of available tooling. That gives me hives, even though it's probably true.

iainctduncan• 5 years ago

People who write these bait-and-switch marketing articles really need to learn that once you do it, you lose potential readers for a long time. There are so many interesting things to read every day - I'm not going to waste any of my precious attention on his writing again after that.

adunk• 5 years ago

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.

lurkerasdfh82• 5 years ago

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.

taneq• 5 years ago

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.)

fulafel• 5 years ago

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?

sitkack2• 5 years ago

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.

Java is running inside of this card, https://zdcard2.en.alibaba.com/product/60655706921-801652433...

akiselev• 5 years ago

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

nneonneo• 5 years ago

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.)

AceJohnny2• 5 years ago

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.

GeorgeTirebiter• 5 years ago

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.

rattray2• 5 years ago

The author started with the premise that V8 won't fit on a microcontroller, but didn't really justify why a new language was needed.

Why would someone choose Toit over Espruino or QuickJS, which seem to promise JS on a microcontroller?

http://www.espruino.com https://bellard.org/quickjs

skybrian2• 5 years ago

It seems like a neat technology but it would be useful to have some concrete examples of what you can do.

The company sales pitch seems to be about fleet management and over-the-air updates. This doesn’t seem very relevant to me considering that I’m a hobbyist flashing a single microcontroller over USB, and I never run more than one program at a time. But perhaps I’m just not the target market and I’m not imagining the right use cases?

buescher5• 5 years ago

Kaspar Lund is very smart and amazingly productive so this sales pitch is disappointing. Amazon's work on formal verification of portions of FreeRTOS, for example, is sophisticated and impressive. What Lund misses in his characterization of FreeRTOS as "primitive" is how much refinement goes into simplicity in embedded work. Here's an example: FreeRTOS' over-the-air update (OTA) mechanism has been formally verified. Why would you formally verify your OTA update mechanism? Because getting OTA updates right is one of those simple things that turns out to be hard. Hard problems aren't solved by just adding another layer of abstraction; my expectation is that it will be more difficult to establish a Toit system is performing correctly than a conventional bare-metal or RTOS-based embedded system.

skybrian2• 5 years ago

I would charitably reinterpret "primitive" more positively like in "language primitives." They are essential.

ngrilly• 5 years ago

I got interested by the idea of a virtual machine for microcontrollers, but I'm less excited about having to use a new dedicated programming language, and the ESP32 being the only supported hardware.

beachy2• 5 years ago

All sounds amazing. On esp32 though I'd settle for simply a way to emulate the TFT display. It gets old re-flashing the device to move a pixel one to the right or to add a println for debugging.

tyingq4• 5 years ago

https://github.com/Ebiroll/qemu_esp32

Has an emulated OLED 1306 display.

beachy2• 5 years ago

Awesome cheers for that.

kgr• 5 years ago

Seems to be heavily influenced by the Smalltalk language and VM. I find it interesting that people will say that embedded microcontrollers are too resource constrained for this type of system, despite many being significantly more powerful than the original Xerox workstations that ran Smalltalk. And those machines were considered mini-computer-class machines at the time.

ostenning2• 5 years ago

Over the past 8 months I’ve been working with Rust on STM32’s and it’s pretty impressive to say the least.

For me, a solid, well documented HAL that works well is key to efficiency in embedded development.

Rusts language features and the ability to abstract things like SPI or I2C peripherals that were once impossible in C are totally doable in Rust, and the community is growing.

Highly recommend checking it out

anthk3• 5 years ago

like SPI or I2C peripherals that were once impossible in C

How so?

ostenning2• 5 years ago

I can write a Rust library for an OLED device that is driven by a platform agnostic I2C device that will run on any microcontroller that implements the necessary abstractions.

The `embedded-hal` (https://github.com/rust-embedded/embedded-hal) are these abstractions that allow this to happen

A virtual machine for microcontrollers

Related Stories