4 ms·

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

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

ashtonkem 5y ago
Or circuit Python. I’m sure there are others too.
jeremyjh 5y 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.
- petre 5y 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.
  - elcritch 5y ago
    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 https://github.com/elcritch/nesper 2: https://www.zephyrproject.org/ https://www.zephyrproject.org/ 3: https://www.nxp.com/design/software/embedded-software/zephyr-os-small-open-source-rtos-for-iot:ZEPHYR-OS https://www.nxp.com/design/software/embedded-software/zephyr...
    - petre 5y ago
      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.
- rattray 5y ago
  What are the shortcomings of Espruino and QuickJS? http://www.espruino.com/ http://www.espruino.com/ https://bellard.org/quickjs/ https://bellard.org/quickjs/
  - lioeters 5y ago
    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-esp32,2 https://www.freelists.org/post/quickjs-devel/quickjs-on-esp3... --- Some attempts on GitHub: https://github.com/binzume/esp32quickjs https://github.com/binzume/esp32quickjs https://github.com/huming2207/quickjs-esp32 https://github.com/huming2207/quickjs-esp32 https://github.com/jack828/esp8266-quickjs https://github.com/jack828/esp8266-quickjs
- discreteevent 5y 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 5y ago
Or Nerves
- jeremyjh 5y 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 5y 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 5y 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?
- buescher 5y 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 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 5y ago
    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 5y ago
      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 5y ago
Also, Forth.

ashtonkem 5y ago

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

jeremyjh 5y 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.

petre 5y 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.
- elcritch 5y ago
  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 https://github.com/elcritch/nesper 2: https://www.zephyrproject.org/ https://www.zephyrproject.org/ 3: https://www.nxp.com/design/software/embedded-software/zephyr-os-small-open-source-rtos-for-iot:ZEPHYR-OS https://www.nxp.com/design/software/embedded-software/zephyr...
  - petre 5y ago
    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.
rattray 5y ago
What are the shortcomings of Espruino and QuickJS? http://www.espruino.com/ http://www.espruino.com/ https://bellard.org/quickjs/ https://bellard.org/quickjs/
- lioeters 5y ago
  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-esp32,2 https://www.freelists.org/post/quickjs-devel/quickjs-on-esp3... --- Some attempts on GitHub: https://github.com/binzume/esp32quickjs https://github.com/binzume/esp32quickjs https://github.com/huming2207/quickjs-esp32 https://github.com/huming2207/quickjs-esp32 https://github.com/jack828/esp8266-quickjs https://github.com/jack828/esp8266-quickjs
discreteevent 5y 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 5y ago

Or Nerves

jeremyjh 5y 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 5y 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 5y 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?

buescher 5y 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 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 5y ago
  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 5y ago
    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 5y ago

Also, Forth.