5 ms·

Is really hard for me to understand how running an VM on a resource constrained device has any benefit. There is a reason why those devices run using very light

Is really hard for me to understand how running an VM on a resource constrained device has any benefit. There is a reason why those devices run using very lightweight "OS"s like FreeRTOS and Embedded C. Why the constant obsession to apply a technology designed for a specific purpose everywhere else, even when it doesn't make sense?

schwartzworld 3y ago
Making it easy for hobbyists who already know that technology to have access. Micropython has been successful, and this is an alternative to that.
- geijoenr 3y ago
  The github project indicates "DeviceScript brings a professional TypeScript developer experience to low-resource microcontroller-based devices." If you tell me is a toy, and somebody's pet project: fine. Is all about having fun. But then don't mention "professional" in the project description.
  - hardware2win 3y ago
    Hmm? Instead of ctrl+f for "professional" I suggest re-reading it >professional TypeScript developer experience It is about experience of sane programming environment, right?
  - schwartzworld 3y ago
    It's not an experience for professional typescript development, but the experience that professional typescript developers are used to. This isn't in competition with C or C++, it's in competition with micropython. Python isn't a great language except in its ubiquity. I'd rather work in what I know, which is TS. This opens up microcontroller development to JavaScript devs of whom there are a lot of us. Types are really helpful when dealing with unfamiliar APIs. When doing embedded projects, you deal with a lot of APIs. There are the language built ins, any libraries you are using to interface with peripherals. This project opens up microcontroller development in a big way to a LOT of developers. Is it what you want to use for a commercial embedded device? I can't say. Is that the only standard? Then you should just be using C for everything, I guess. But something like a Raspberry Pi Pico or ESP32 has plenty of resources to run JavaScript while still being able to manage a weather station or automated garden or security camera or pen plotter. There are lots of applications that don't use the full power of the board.
iamflimflam1 3y ago
Java was originally intended for embedded devices...
pjc50 3y ago
It's not a bad decision for scripting provided the VM is lightweight enough. Things like "FORTH interpreter" or the old "BASIC stamp" microcontrollers. And it provides a degree of robustness vs running arbitrary binaries.
classified 3y ago
A VM can make all the gaping security holes portable between IOT devices.
- manmal 3y ago
  I appreciate the tongue-in-cheek, but I think there‘s really the chance for better IoT security when using a VM. Those things are connected to the internet (duh) and sandboxing is probably a good idea. You obviously don’t need a VM for that, but maybe the tradeoffs are favorable.
  - mrguyorama 3y ago
    99% of the security issues in the IoT things are software design stupidity. Using a "safe" language or "sandboxed" VM cannot save your lightbulb when it's main loop includes "fill buffer with content from HTTP endpoint and execute it"
suprfnk 3y ago
Easy: because TypeScript or Python are way easier to learn than C. Learning C is a long, arduous, uphill battle against arcane error messages and undefined behaviour. Unless you have a background in C/C++ already, most people can probably get up and running with something like this way, way faster.
- TheLoafOfBread 3y ago
  How do you get that TypeScript or Python environment on the chip of your interest at the first place? How do you expose hardware interfaces without knowledge of C?
  - eropple 3y ago
    > How do you get that TypeScript or Python environment on the chip of your interest at the first place? By having somebody else do it. Abstraction is a wonderful thing.
    - TheLoafOfBread 3y ago
      That's just kicking the can down the road. What if you are working on device which is under NDA? What if it is some exotic MCU which nobody else uses?
      - jon-wood 3y ago
        Then you probably shouldn’t use this. It’s not for you, that’s cool, move on and use whatever you’re currently using.
        TheLoafOfBread 3y ago
        I am just showing you that DeviceScript/MicroPython/LUA/any other scripting language will expect from the user to know lot of C in order to be able to use its board unless they want to just run it without any input/output of data. But users want to use the scripting language because they don't know C. The whole flow is Catch-22.
pjmlp 3y ago
8 and 16 bit home computing says hello.
jononor 3y ago
One of they main reasons was that they had to: the cost of a more capable system was too high. In the last years that has improved drastically, and there are many usecases where the 5 USD increase in BOM needed to run JS/Python etc can be justified.
- mmoskal 3y ago
  Exactly! But it's more like 1.50 USD (ESP32-C3 or RP2040 compared to say STM8).
TheLoafOfBread 3y ago
I agree, this will mostly go nowhere. Sure when somebody will prepare you DeviceScript environment for *your* board, then you are good to go. But in 99% of cases, you will get hardware in front of you which almost certainly is not supported by DeviceScript. And now without intimate knowledge of C, how are you going to expose interfaces of that particular hardware, so you can work with those interfaces in DeviceScript? Well you won't, you need to know C first. Same problem for MicroPython. Same problem for LUA, same problem for any scripting language running on constrained MCU.
- jononor 3y ago
  The target audience for such runtimes are teams with general software engineer skills, and less embedded skills, and little hardware skills. They are likely to weight software support (including drivers) very heavily when selecting hardware. This reduces how often the scenario you describe will come up, compared to traditional hardware development.
  - claytongulick 3y ago
    Yep. For example, it supports ESP32. Every problem sure starts to look like a ESP32 nail if I have this tool chain available.
    - HeyLaughingBoy 3y ago
      Depending on the kind of work you do, this may not be a problem. For my day job, I use STM32/C++ because it's what the company has standardized on. For my side gig/consulting work, I've pretty much standardized on ESP32 because it's cheap, has lots of resources and good community, and I can leverage the Arduino ecosystem. It's grossly overkill for a lot of projects but no-one cares. Clients just care that you can ship fast. My next step is moving the side gig work to MicroPython or some other higher-level language that lets me code much faster than C/C++.
      - claytongulick 3y ago
cprecioso 3y ago
Say that to the millions of ID cards, transport cards, SIM cards, and other smart cards with a secure element that run Java (a lot of times only powered by the small current from the NFC tap).
mrguyorama 3y ago
The Apollo program went to the moon with a complex VM on top of an extremely limited physical architecture. That's actually one of the main reasons to do it, because you can implement a strictly better (in all sorts of ways) virtual machine on top of really awful hardware. Not to say that's valid in this instance, but plenty of early VMs were entirely made to improve resource constrained hardware

schwartzworld 3y ago

Making it easy for hobbyists who already know that technology to have access. Micropython has been successful, and this is an alternative to that.

geijoenr 3y ago
The github project indicates "DeviceScript brings a professional TypeScript developer experience to low-resource microcontroller-based devices." If you tell me is a toy, and somebody's pet project: fine. Is all about having fun. But then don't mention "professional" in the project description.
- hardware2win 3y ago
  Hmm? Instead of ctrl+f for "professional" I suggest re-reading it >professional TypeScript developer experience It is about experience of sane programming environment, right?
- schwartzworld 3y ago
  It's not an experience for professional typescript development, but the experience that professional typescript developers are used to. This isn't in competition with C or C++, it's in competition with micropython. Python isn't a great language except in its ubiquity. I'd rather work in what I know, which is TS. This opens up microcontroller development to JavaScript devs of whom there are a lot of us. Types are really helpful when dealing with unfamiliar APIs. When doing embedded projects, you deal with a lot of APIs. There are the language built ins, any libraries you are using to interface with peripherals. This project opens up microcontroller development in a big way to a LOT of developers. Is it what you want to use for a commercial embedded device? I can't say. Is that the only standard? Then you should just be using C for everything, I guess. But something like a Raspberry Pi Pico or ESP32 has plenty of resources to run JavaScript while still being able to manage a weather station or automated garden or security camera or pen plotter. There are lots of applications that don't use the full power of the board.

iamflimflam1 3y ago

Java was originally intended for embedded devices...

pjc50 3y ago

It's not a bad decision for scripting provided the VM is lightweight enough. Things like "FORTH interpreter" or the old "BASIC stamp" microcontrollers. And it provides a degree of robustness vs running arbitrary binaries.

classified 3y ago

A VM can make all the gaping security holes portable between IOT devices.

manmal 3y ago
I appreciate the tongue-in-cheek, but I think there‘s really the chance for better IoT security when using a VM. Those things are connected to the internet (duh) and sandboxing is probably a good idea. You obviously don’t need a VM for that, but maybe the tradeoffs are favorable.
- mrguyorama 3y ago
  99% of the security issues in the IoT things are software design stupidity. Using a "safe" language or "sandboxed" VM cannot save your lightbulb when it's main loop includes "fill buffer with content from HTTP endpoint and execute it"

suprfnk 3y ago

Easy: because TypeScript or Python are way easier to learn than C. Learning C is a long, arduous, uphill battle against arcane error messages and undefined behaviour. Unless you have a background in C/C++ already, most people can probably get up and running with something like this way, way faster.

TheLoafOfBread 3y ago
How do you get that TypeScript or Python environment on the chip of your interest at the first place? How do you expose hardware interfaces without knowledge of C?
- eropple 3y ago
  > How do you get that TypeScript or Python environment on the chip of your interest at the first place? By having somebody else do it. Abstraction is a wonderful thing.
  - TheLoafOfBread 3y ago
    That's just kicking the can down the road. What if you are working on device which is under NDA? What if it is some exotic MCU which nobody else uses?
    - jon-wood 3y ago
      Then you probably shouldn’t use this. It’s not for you, that’s cool, move on and use whatever you’re currently using.
      - TheLoafOfBread 3y ago
        I am just showing you that DeviceScript/MicroPython/LUA/any other scripting language will expect from the user to know lot of C in order to be able to use its board unless they want to just run it without any input/output of data. But users want to use the scripting language because they don't know C. The whole flow is Catch-22.

pjmlp 3y ago

8 and 16 bit home computing says hello.

jononor 3y ago

One of they main reasons was that they had to: the cost of a more capable system was too high. In the last years that has improved drastically, and there are many usecases where the 5 USD increase in BOM needed to run JS/Python etc can be justified.

mmoskal 3y ago
Exactly! But it's more like 1.50 USD (ESP32-C3 or RP2040 compared to say STM8).

TheLoafOfBread 3y ago

I agree, this will mostly go nowhere. Sure when somebody will prepare you DeviceScript environment for *your* board, then you are good to go. But in 99% of cases, you will get hardware in front of you which almost certainly is not supported by DeviceScript. And now without intimate knowledge of C, how are you going to expose interfaces of that particular hardware, so you can work with those interfaces in DeviceScript? Well you won't, you need to know C first. Same problem for MicroPython. Same problem for LUA, same problem for any scripting language running on constrained MCU.

jononor 3y ago
The target audience for such runtimes are teams with general software engineer skills, and less embedded skills, and little hardware skills. They are likely to weight software support (including drivers) very heavily when selecting hardware. This reduces how often the scenario you describe will come up, compared to traditional hardware development.
- claytongulick 3y ago
  Yep. For example, it supports ESP32. Every problem sure starts to look like a ESP32 nail if I have this tool chain available.
  - HeyLaughingBoy 3y ago
    Depending on the kind of work you do, this may not be a problem. For my day job, I use STM32/C++ because it's what the company has standardized on. For my side gig/consulting work, I've pretty much standardized on ESP32 because it's cheap, has lots of resources and good community, and I can leverage the Arduino ecosystem. It's grossly overkill for a lot of projects but no-one cares. Clients just care that you can ship fast. My next step is moving the side gig work to MicroPython or some other higher-level language that lets me code much faster than C/C++.
    - claytongulick 3y ago

cprecioso 3y ago

Say that to the millions of ID cards, transport cards, SIM cards, and other smart cards with a secure element that run Java (a lot of times only powered by the small current from the NFC tap).

mrguyorama 3y ago

The Apollo program went to the moon with a complex VM on top of an extremely limited physical architecture. That's actually one of the main reasons to do it, because you can implement a strictly better (in all sorts of ways) virtual machine on top of really awful hardware. Not to say that's valid in this instance, but plenty of early VMs were entirely made to improve resource constrained hardware