One of the biggest challenges will be drivers for the actual hardware - at the moment it looks like they have support for SPI and for built in LEDs. But it's a big challenge to expose all the different peripherals that come with MCUs in a consistent way.
Actually, looks like they've got quite a lot of stuff done already:
With MicroPython you can have C drivers and just do the MicroPython bindings. I do not see the benefits of having yet another interpreted IoT language and it does not make sense to do the drivers in the interpreted language itself.
Is the only reason for this to make it possible for web developers or people who know TypeScript to write code for IoT Devices? To fill the lack of experienced low level programmers? Because as language alone, I don't see a reason why I should I ever use this if I am not familiar with TypeScript already.
There are a number of reasons to do this. This sort of setup typically has the VM runtime flashed into the microprocessor's program space with the interpreted byte code stored in data space --- either internal or external.
1) It is obviously not as fast as native but it is fast enough for a lot of applications. In embedded work, you don't get extra credit for being faster than necessary. Speed critical functions like communications are mostly handled at native speed by the VM.
2) Code size. Interpreted byte code (minus the VM) can be smaller and less redundant than native. And by adding cheap external storage, code can easily expand beyond the native program space of the micro.
3) Easy remote updates. Byte code can be received and stored without making changes to the micro's program code (no re-flashing required). It's possible to fix bugs and make changes or even completely repurpose the hardware from afar.
>Is the only reason for this to make it possible for web developers or people who know TypeScript to write code for IoT Devices? To fill the lack of experienced low level programmers?
Which is funny because there's no lack of low level programmers in my experience.
Companies just try and pay Embedded Systems Engineers and Electrical Engineers dirt compared to "Software Engineers". In the same part of NY where SWE base salaries are $160k+, they will offer $120k for the same years of experience to a EE/Embedded SWE. And these are both major companies (non-big tech) and small companies that will do this.
Of course I also see those job postings for those specific companies last a long time here. There's one going for 3 years now for a many decades old small defense contractor that's even had their CTO directly reach out to me. Meanwhile I sit pretty in my actually respectable paying embedded job that I ain't jumping ship for a paycut.
I started my career in C/C++ and embedded. Every time I go back to work on embedded stuff for fun, it's like going back in time and losing all of the nice things that come with languages like TypeScript or JS. Suddenly things like associative arrays, maps, sets, lists, vectors - all require much more mental overhead to deal with and ultimately get in the way of what I actually want to be doing.
My personal opinion is that good typescript to C transpiller would do a way better job, tons of microcontrollers supported out of the box. I would be also happy to use it for desktop. With some tricks it could even support references and additional numeric data types (u8, i8 ... ) without breaking any syntax
I think a language that just transpiled to the equivalent C would be pretty awesome. I know Google is building Carbon, but it is more focused on C++. They pitch it as Typescript to JavaScript, Scala to Java, Carbon to C++.
Instead of Rust or Zig trying to replace C++ or Java, is seems better to just integrate with it without linking through some FFI.
I'm working on some C code for some microcontroller since it was too difficult to use Rust.
Does such a thing exist? I would love something like that, but is it even feasible? Isn’t there a lot more you need to be aware of, to make a translation of say TS’s objects into C?
Funny, the fact that typescript is "only" structurally typed is one of my main pain points with the language. (Of course it's tons better than vanilla JS)
> == and != operators (other than == null/undefined); please use === and !===
That's a whole lot of equals signs.
Typos aside, this all looks really amazing!
Although by no means sound, the ergonomics of TypeScript's type system are phenomenal. Really glad to see additional use cases beyond traditional JS runtimes.
Typescript has to inherit this typing madness because it’s strictly a Javascript superset. As a decade long JS developer, I avoid == and != like plague because of type castings and funny results that I don’t bother to remember.
There are plenty of usecases for electronics which is not high volume. And many cases where the BOM margin are not the cost driver, such as when installation/setup costs dominate. And projects where cost is secondary to thing like time-to-market, ability to integrate/customize et.c.
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?
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).
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.
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
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.
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.
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.
This looks really promising and that's coming from someone who used to hand roll assembly for my hardware projects in uni. Since my day to day focus is elsewhere these days I need a setup that will hold my hand and hide away as many footguns as possible. I'm already familiar with Typescript so using the same language in a different environment is a win. Having that system be backed by a large company is a great boon as well, as it means there's a somewhat smaller chance of it disappearing from underneath me (Google's projects notwithstanding).
I’ve been mixed about using alternative languages or specialized runtimes on IoT devices and while I think an inherently event-driven language like JavaScript, with its first-class function as value support and widely used patterns, I’ve been of the mind lately that building firmware with these tools may be the wrong approach.
First, most IoT device behavior can be described with a finite number of actions, and usually revolves around reading and writing bits to a bus (I2C/TWI, SPI, USART, CAN) or GPIO. Hardware is only really configured once and ran forever.
I think there is a place for a hardware system that self-describes to an entity and receives a bytecode procedure for each phase of its operation. This byte code can be made small because there are not many operations to really be done and the firmware would just directly execute it and handle updates, versions, and device abstractions.
I don't think there's anything inherently event-based in JavaScript the language, it's just how the browser API works. You can just as easily write busy loops.
Sounds a bit similar to assemblyscript. I wonder if there's a connection between those projects. Assembly script targeting WASM on small devices might be useful.
We need to add a doc page about relationship with WASM...
In short, WASM was not designed to be interpreted, and definitely not on small devices. The DeviceScript VM bytecode is designed to run directly from flash (read-only memory of which you have typically 10x more on an embedded system), with minimal overheads.
Also WASM is not designed as a runtime for a dynamic language, eg., + operator would be for two i32 and what you really want for JavaScript semantics is to have a + operator that works on strings, NaN-boxed numbers, etc.
As for AssemblyScript, I guess it's meant as language for small fragments of your code, not the whole application. For application you would be probably better off with Rust or similar and native compilation.
Microsoft is really doing amazing with FOSS lately. The only things I see missing are some kind of filesystem. It doesn't seem quite ready to replace CircuitPython but probably will in time.
The big potential I see here is App-capable devices. That's really the missing factor with the IoT right now, the apps are separate from the device. We have to adapt everything around it to be able to talk to it, and usually you can't because it's all proprietary.
But if we had an OS and an App store, any device would work with anything.
We could actually get some good use out of Matter being IP based, if we could run apps on our smart plug.
It would be especially great for things that have a display.
I'm not sure why nobody has made an IoT OS with an app store yet, but it would/will be awesome.
> The main difference in semantics between DeviceScript and JavaScript is that DeviceScript programs run in multiple fibers (threads). In practice, this behaves like JS with async/await but without an ability to manipulate promises directly (that is fibers can only interleave at await points and at most one fiber runs at any given time).
The language seems rather complete [L], which makes me wonder: would that byte interpreter be of any use in other environments? How fast is it compared to e.g. V8 and JavaScriptCore? And to µPython?
It should about the same as uPython. There is a few more tricks we can play due to whole program compilation but I don't think we take advantage of that yet.
This looks great but needs a non-frictiony way to bolt together with some C or assembly code where needed. Not sure about JADAC, and wondering how hard it would be to write libraries / servers / whatever for sensors, DMA, ADC, etc.
Also note docs say "Serial, SPI, PWM are not supported yet at the DeviceScript level."
SPI is now supported (though only on ESP32 right now; PRs are welcome elswhere!), just fixed the docs. DMA is typically bundled with some other driver (like SPI).
We do support ADC - there is even a funky way of exposing these nicely as Jacdac servers so they show on debugging dashboards [0]
It’s odd that the S3 isn’t supported when the S2 is the same LX7 based core and as far as ESP-IDF bring up is concerned it’s pretty much just some io_mux_reg and other definitions (at least when I ported Nesper to the S3 from the original ESP32 project)
Though it also seems like it doesn’t use both of the LX7 cores:
This might be suitable for dumb IoT devices that are connected to a power adapter, but as soon as you begin working with battery powered products, time critical systems, or require to reduce BoM costs, this sort of thing goes out the window.
Finally, I've been waiting for this for years now!
Now it's just a matter of continuing to expand the integrations. Will have to look at what the process looks like for creating custom integrations for existing libraries when non exist.
Microsoft has a long history of fracturing programming language markets. It's not so much that it is a bad idea, more that it divides an already healthy market. There is MicroPython, Arduino, and Node-RED not to mention all of the C/C++ based systems out there: mBed, Zephyr, and RIOT OS. Another addition is not helpful.
samwillis|2 years ago
dang|2 years ago
DeviceScript: TypeScript for Tiny IoT Devices - https://news.ycombinator.com/item?id=36059878 - May 2023 (101 comments)
iamflimflam1|2 years ago
Actually, looks like they've got quite a lot of stuff done already:
https://microsoft.github.io/devicescript/api/clients https://microsoft.github.io/devicescript/api/servers
user_account|2 years ago
jononor|2 years ago
nicce|2 years ago
jqpabc123|2 years ago
1) It is obviously not as fast as native but it is fast enough for a lot of applications. In embedded work, you don't get extra credit for being faster than necessary. Speed critical functions like communications are mostly handled at native speed by the VM.
2) Code size. Interpreted byte code (minus the VM) can be smaller and less redundant than native. And by adding cheap external storage, code can easily expand beyond the native program space of the micro.
3) Easy remote updates. Byte code can be received and stored without making changes to the micro's program code (no re-flashing required). It's possible to fix bugs and make changes or even completely repurpose the hardware from afar.
delfinom|2 years ago
Which is funny because there's no lack of low level programmers in my experience.
Companies just try and pay Embedded Systems Engineers and Electrical Engineers dirt compared to "Software Engineers". In the same part of NY where SWE base salaries are $160k+, they will offer $120k for the same years of experience to a EE/Embedded SWE. And these are both major companies (non-big tech) and small companies that will do this.
Of course I also see those job postings for those specific companies last a long time here. There's one going for 3 years now for a many decades old small defense contractor that's even had their CTO directly reach out to me. Meanwhile I sit pretty in my actually respectable paying embedded job that I ain't jumping ship for a paycut.
iamflimflam1|2 years ago
I suspect the target audience is more on the hobbyist/non embedded programmer side of things.
nanidin|2 years ago
naikrovek|2 years ago
Excellent tooling exists for you if your language is TypeScript, so maybe try putting TypeScript in more places.
iampims|2 years ago
benniomars|2 years ago
[deleted]
danielEM|2 years ago
simlevesque|2 years ago
devmunchies|2 years ago
Instead of Rust or Zig trying to replace C++ or Java, is seems better to just integrate with it without linking through some FFI.
I'm working on some C code for some microcontroller since it was too difficult to use Rust.
jeppester|2 years ago
onimishra|2 years ago
andrewstuart|2 years ago
It’s a nightmare trying to deal with bundling and compiling and targets and different import schemes ugh.
I wish I could compile my programs it compiles all the stuff in node modules and gives me some working code.
Desperate to get away from nodejs I tried deno and bun …. neither of them are anything close to a drop in replacement for nodejs.
black_puppydog|2 years ago
Funny, the fact that typescript is "only" structurally typed is one of my main pain points with the language. (Of course it's tons better than vanilla JS)
k__|2 years ago
Benjamin_Dobell|2 years ago
That's a whole lot of equals signs.
Typos aside, this all looks really amazing!
Although by no means sound, the ergonomics of TypeScript's type system are phenomenal. Really glad to see additional use cases beyond traditional JS runtimes.
thangngoc89|2 years ago
littlecranky67|2 years ago
mmoskal|2 years ago
biosboiii|2 years ago
Cost cutting in high volume electronics is crazy.
jononor|2 years ago
geijoenr|2 years ago
Why the constant obsession to apply a technology designed for a specific purpose everywhere else, even when it doesn't make sense?
cprecioso|2 years ago
iamflimflam1|2 years ago
pjc50|2 years ago
mrguyorama|2 years ago
Not to say that's valid in this instance, but plenty of early VMs were entirely made to improve resource constrained hardware
schwartzworld|2 years ago
suprfnk|2 years ago
Unless you have a background in C/C++ already, most people can probably get up and running with something like this way, way faster.
jononor|2 years ago
pjmlp|2 years ago
TheLoafOfBread|2 years ago
Same problem for MicroPython. Same problem for LUA, same problem for any scripting language running on constrained MCU.
classified|2 years ago
Etheryte|2 years ago
samtho|2 years ago
First, most IoT device behavior can be described with a finite number of actions, and usually revolves around reading and writing bits to a bus (I2C/TWI, SPI, USART, CAN) or GPIO. Hardware is only really configured once and ran forever.
I think there is a place for a hardware system that self-describes to an entity and receives a bytecode procedure for each phase of its operation. This byte code can be made small because there are not many operations to really be done and the firmware would just directly execute it and handle updates, versions, and device abstractions.
chpatrick|2 years ago
jillesvangurp|2 years ago
mmoskal|2 years ago
In short, WASM was not designed to be interpreted, and definitely not on small devices. The DeviceScript VM bytecode is designed to run directly from flash (read-only memory of which you have typically 10x more on an embedded system), with minimal overheads.
Also WASM is not designed as a runtime for a dynamic language, eg., + operator would be for two i32 and what you really want for JavaScript semantics is to have a + operator that works on strings, NaN-boxed numbers, etc.
As for AssemblyScript, I guess it's meant as language for small fragments of your code, not the whole application. For application you would be probably better off with Rust or similar and native compilation.
oneplane|2 years ago
iamflimflam1|2 years ago
* TypeScript for IoT: The familiar syntax and tooling, all at your fingertips.
* Small Runtime: Bytecode interpreter for low power/flash/memory.
* Hardware as Services: Client/server architecture for sensors and actuators.
* Debugging: In Visual Studio Code, for embedded hardware or simulated devices.
* Simulation and Testing: Develop and test your firmware using hardware/mock sensors. CI friendly.
* Development Gateway: Prototype cloud service with device management, firmware deployment and message queues.
https://microsoft.github.io/devicescript/
eternityforest|2 years ago
The big potential I see here is App-capable devices. That's really the missing factor with the IoT right now, the apps are separate from the device. We have to adapt everything around it to be able to talk to it, and usually you can't because it's all proprietary.
But if we had an OS and an App store, any device would work with anything.
We could actually get some good use out of Matter being IP based, if we could run apps on our smart plug.
It would be especially great for things that have a display.
I'm not sure why nobody has made an IoT OS with an app store yet, but it would/will be awesome.
juancampa|2 years ago
tgv|2 years ago
[L] https://microsoft.github.io/devicescript/language
mmoskal|2 years ago
paulddraper|2 years ago
(26 May 2023) https://news.ycombinator.com/item?id=36079842
rkagerer|2 years ago
This looks great but needs a non-frictiony way to bolt together with some C or assembly code where needed. Not sure about JADAC, and wondering how hard it would be to write libraries / servers / whatever for sensors, DMA, ADC, etc.
Also note docs say "Serial, SPI, PWM are not supported yet at the DeviceScript level."
mmoskal|2 years ago
We do support ADC - there is even a funky way of exposing these nicely as Jacdac servers so they show on debugging dashboards [0]
As for S3, PRs are welcome! :)
[0] https://microsoft.github.io/devicescript/developer/servers/a...
girvo|2 years ago
Though it also seems like it doesn’t use both of the LX7 cores:
> and at most one fiber runs at any given time
ostenning|2 years ago
ranguna|2 years ago
Now it's just a matter of continuing to expand the integrations. Will have to look at what the process looks like for creating custom integrations for existing libraries when non exist.
pjmlp|2 years ago
Microsoft's MakeCode project already provides something similar, via compilation to C++, for quite some time now.
unknown|2 years ago
[deleted]
user_account|2 years ago
thawab|2 years ago
- It's a different language/project, therefor no embrace or extending happening.
- It's just 2 hackers working in microsoft, we don't have to dismiss their work because their employer actions years ago.
- It's open source.
nimish|2 years ago
Already__Taken|2 years ago
TheLoafOfBread|2 years ago
Benjamin_Dobell|2 years ago
dboreham|2 years ago
paulddraper|2 years ago
NathanielBaking|2 years ago
pjmlp|2 years ago