[HN Gopher] A virtual machine for microcontrollers
___________________________________________________________________
A virtual machine for microcontrollers
Author : tosh
Score : 161 points
Date : 2021-06-01 12:03 UTC (10 hours ago)
(HTM) web link (blog.toit.io)
(TXT) w3m dump (blog.toit.io)
| tosh wrote:
| 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 wrote:
| 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.
| dahart wrote:
| 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.
| CodeWriter23 wrote:
| We had MP/M in 1979.
| dahart wrote:
| Right, and there was even Multics in 1969. I was giving
| some benefit of the doubt, but I feel like Ingall's quote
| was pretty dodgy even in 1981. Maybe it was tongue in
| cheek, or being intriguing and controversial just to get
| readers? Maybe there is some point of view that I'm
| completely missing?
| CalChris wrote:
| I don't think you're missing anything. That was a very
| Smalltalk way of thinking at the time. However it flies
| in the face of separation of concerns, security,
| experience, .... It's a colorful quote but the
| marketplace of ideas hasn't been kind to it.
| Koshkin wrote:
| No, an OS is what you see when you turn the damned thing on.
| dragonwriter wrote:
| > 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.
| 542458 wrote:
| 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 wrote:
| 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)
| deepzn wrote:
| Can running WASM solve this?
| vajrabum wrote:
| 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.
| twic wrote:
| 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!
| leoedin wrote:
| 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.
| kabdib wrote:
| 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.
| buescher wrote:
| 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.
| skybrian wrote:
| 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?
| eqvinox wrote:
| 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.
| pjmlp wrote:
| 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...
| eqvinox wrote:
| 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.
| buescher wrote:
| 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_SC
| RU...
| scoutt wrote:
| > 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 wrote:
| 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.
| scoutt wrote:
| I agree with what you wrote.
|
| > there's no point to distinguish them
|
| I think the distinction should be clearly made when someone
| wants to sell me something like Rust. They come up with the
| daily link about 70% of the bugs are memory issues plus
| something in the lines of _" memory vulnerabilities! think
| about the hackers! exploits!"_, when it's clear that these
| arguments don't _click_ in (many areas of) embedded. Safety
| and security have another meaning. The steal of a password
| is the least of my fears, if I think a bad implementation
| of mine can chop-off the hand of an operator.
| eqvinox wrote:
| The distinction is made quite clearly, one is safety, the
| other is security :)
|
| (while the terms are intermixed in general discourse,
| both the embedded and security worlds consistently
| separate the two, at least in everything I've seen)
| baybal2 wrote:
| Indeed,
|
| And VM == bye bye JTAG debugging, which makes it DOA for most
| developers past the Arduino level.
| irjustin wrote:
| 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.
| jeremyjh wrote:
| So this is a shameless bit of marketing collateral but I also
| learned from it. I hadn't heard of Toit before.
| sebe wrote:
| 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
| tyingq wrote:
| 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.
| zozbot234 wrote:
| 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.
| phpnode wrote:
| V8 has an interpreter now FWIW
| https://v8.dev/blog/ignition-interpreter
| tyingq wrote:
| The ESP32 has IRAM, which you can write to and execute
| from.
| codys wrote:
| A large number of microcontrollers are ARM based, which
| isn't Harvard architecture. I presume the thinking is that
| there's some massive number of Harvard architecture chips
| in mundane things that lets us say "most" are Harvard arch?
| jeremyjh wrote:
| ARM Cortex-M is a harvard architecture microcontroller.
| What ARM Cortex-M has in common with ARMv8 are the
| letters "ARM".
| tyingq wrote:
| "Modified" Harvard though. The M0 has unified main
| memory, so JIT wouldn't be immediately ruled out.
| zozbot234 wrote:
| Some Cortex-M cores are described as Von Neumann. It
| varies by specific sub-architecture within Cortex M.
| zozbot234 wrote:
| Many ARM microcontrollers have Harvard architecture as
| well, for improved interrupt latency compared to plain
| Von Neumann.
| finnthehuman wrote:
| > 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.
| abraae wrote:
| 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.
| ostenning wrote:
| 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
| anthk wrote:
| > like SPI or I2C peripherals that were once impossible in C
|
| How so?
| hrishi wrote:
| 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.
| scoutt wrote:
| 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.
| sebe wrote:
| 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
| MayeulC wrote:
| 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.
| pjmlp wrote:
| 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/
| qayxc wrote:
| Not to mention languages that can be compiled to C.
| scoutt wrote:
| > 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.
| MayeulC wrote:
| > I knew that this would be mentioned but I didn't want to
| write an extensive comment.
|
| Oh, me neither, and I wasn't really talking of big
| production runs. If you have tight margins, you better take
| anything you can, and C is probably one of the first tools
| at your disposal.
|
| > 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".
|
| You'd be surprised. The Harmony remotes comes to mind as an
| (old) example. In environments such as startups, time to
| market sometimes trumps even common sense. And people
| (including you and me) just prefer the tools they know
| most.
|
| > Personally I wouldn't know where to start with
| micropython.
|
| Funnily, I have never used it (except for a bit on a
| numworks calculator), but I can't imagine it being
| difficult once it's up and running on your microcontroller
| of choice. You probably flash and run as usual, except it's
| python code and has a repl.
| pjmlp wrote:
| Pretend it is just like C64, Z80 BASIC, or BASIC Stamp.
| scoutt wrote:
| See??? Because you don't want to learn C now you have to
| learn Toit, Python, BASIC and another two subpar-
| performance languages!!! :)
| pjmlp wrote:
| My first computer was a Timex 2068, and I learned C long
| time ago, enough to be dangerous and knowing only to
| touch it when there is no other _modern_ option
| available.
|
| Most of the stuff people do in the Makers community is
| more than doable with Micro/CircuitPython + a bit of
| Assembly.
| jmiskovic wrote:
| I found micropython to be quite valuable in board bring-up
| stage. It is nice to be able to interactively test
| peripherals in repl, and these interactive sessions can be
| solidified in C code. This article about prototyping esp32
| in micropython is great example:
| https://nick.zoic.org/art/lilygo-ttgo-t-watch-2020/
| cozzyd wrote:
| You can always abuse gdb as a repl with a programmer and
| a spare static buffer.
| rurban wrote:
| Not on many microcontrollers, where you have no room for
| the debugging uart ports. I never had the luxury of gdb
| on my baremetal firmwares, only via selfwritten
| simulators or emulators. not qemu, qemu supports nothing.
| renode or unicorn are pretty good.
| iainctduncan wrote:
| 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.
| phoe-krk wrote:
| 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.
| lebuffon wrote:
| 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?
| buescher wrote:
| 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.
| elcritch wrote:
| IIRC, in the 90's there were several Forth implementations
| that worked as described and appeared to have been somewhat
| successful in the embedded market. Those were before my
| time though.
|
| However, with the amount of RAM/FLASH on modern MCU's you
| can implement the "compiler" code in Forth. I used a
| similar scheme for a while during experimental phases, but
| have moved away as Forth code becomes tedious to modify
| after you haven't looked at it for a while (e.g. a few
| weeks). It's just easier to setup OTA firmware updates.
| buescher wrote:
| I assume Forth, Inc's stuff works and I assume it's still
| around, but I've never used it. Forth is lots of fun
| compared to languages with curly braces so it's too bad
| it was already on its way out back then.
|
| Modern MCUs have so much RAM and flash you could probably
| run a whole 1980s style development enviroment on them
| (think say, Turbo Pascal and a collection of tools) on a
| console, TUI and all.
| anthk wrote:
| Check FlashForth.
| i_don_t_know wrote:
| 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.
| anthk wrote:
| Also, Forth.
| ashtonkem wrote:
| Or circuit Python. I'm sure there are others too.
| jeremyjh wrote:
| 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.
| rattray wrote:
| What are the shortcomings of Espruino and QuickJS?
|
| http://www.espruino.com/
|
| https://bellard.org/quickjs/
| lioeters wrote:
| If the scope is limited to ESP32/ESP8266, it seems
| technically possible to run QuickJS on them.
|
| From Fabrice Bellard himself:
|
| > QuickJS should be able to run on the ESP32 platform as it
| is OS independent (as you said, quickjs-libc.c is not part
| of the engine). For simple scripts it should fit in the
| available RAM.
|
| https://www.freelists.org/post/quickjs-devel/quickjs-on-
| esp3...
|
| ---
|
| Some attempts on GitHub:
|
| https://github.com/binzume/esp32quickjs
|
| https://github.com/huming2207/quickjs-esp32
|
| https://github.com/jack828/esp8266-quickjs
| petre wrote:
| 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.
| elcritch wrote:
| Not quite sure if I follow what you're saying. As in
| Tasmota/Berry do or do not do more than provide I2C/SPI?
|
| > If one wants to do serious stuff they would use an
| appropriate RTOS and program it in C.
|
| It's unfortunate, but still largely appears to be the case.
| I find C very time consuming to program, so I ported Nim to
| FreeRTOS [1]. It's _very_ nice being able to go from
| writing highly optimized ISR functions to high level JSON
| parsing in one language. Add in defaulting to memory safety
| but with no pause-the-world GC. I tried Rust but it seems
| more difficult to integrate into existing world RTOS'es,
| flashers, Swagger debuggers, etc.
|
| Though, I've been curious what running a WASM VM would be
| like? One could integrate any language: C++, C, Nim, Rust,
| etc. Would be interesting.
|
| > 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.
|
| MongooseOS does seem interesting, but very targeting a
| niche market with prebuilt needs? For future RTOS'es I
| think ZephyrOS [2] has a lot of potential given it's now
| supported by NXP [3], TI, and others but is independent of
| any given (cloud) vendors or other IoT companies. Some
| might not like the CMake based build system, but in my view
| all the RTOS build systems are terrible in their own
| special way.
|
| 1: https://github.com/elcritch/nesper 2:
| https://www.zephyrproject.org/ 3:
| https://www.nxp.com/design/software/embedded-
| software/zephyr...
| petre wrote:
| Tasmota has drivers for almost anything you'd imagine.
| Adding I2C or OW sensors for instance is mostly plug and
| play. If you wired them correctly and used tge
| appropriate image they would just work. Berry is an addon
| scripting kanguage that runs on a VM. It's only present
| in the ESP32 dev branch.
|
| Zephyr is nice and well documented but support for ESP
| devices is quite lacking. For NXP devices it's great.
| discreteevent wrote:
| >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 wrote:
| Or Nerves
| jeremyjh wrote:
| 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.
| adunk wrote:
| 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.
| akiselev wrote:
| 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 wrote:
| 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.)
| zozbot234 wrote:
| 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.
| lurkerasdfh8 wrote:
| 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 wrote:
| 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.)
| lurkerasdfh8 wrote:
| > is very much embedded
|
| 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.
|
| And there are perfectly fine open source solutions with the
| same goals, such as
| https://archive.fosdem.org/2020/schedule/event/ioterlang/
| [deleted]
| zozbot234 wrote:
| 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.)
| apaprocki wrote:
| ... but if you _do_ want a modern JS engine running on a
| microcontroller:
|
| https://github.com/Moddable-OpenSource/moddable#moddable-sdk
| the__alchemist wrote:
| > 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.
| ashtonkem wrote:
| 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 wrote:
| 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".
| pjmlp wrote:
| Indeed, if one moves into maker community there have been
| Basic, Pascal, Oberon, Java compilers for ages.
|
| Those companies manage to stay in business selling such
| compilers for at least three decades now, which kind of
| proves there is a market of people willing to pay for them,
| instead of going with C like everyone else.
| markdeloura wrote:
| 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.
| ngrilly wrote:
| 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.
| buescher wrote:
| 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.
| rattray wrote:
| 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
| kgr wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-01 23:02 UTC)