DeviceScript: TypeScript for Tiny IoT Devices - https://news.ycombinator.com/item?id=36059878 - May 2023 (101 comments)
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
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.
For battery powered devices, you absolutely do. When you're talking over a slower protocol, being able to put the processor to sleep for 95% of the time can translate to pretty massive power savings.
You absolutely do when you can cut power requirements and get by with cheaper CPU/hardware. I ran a whole consulting business redesigning poorly designed devices and redoing firmware for cost reduction. How does one decide “necessary”, what is necessary in the short and long term are often not the same.
1) you get shorter battery life for slower code. Also, everything is speed critical anyways. It sucks when I’m controlling my toy robot and it’s trying to drive into the floor while doMyStuff(); has its head stuck in float math.
2) external anything is added cost to everything; adding an SPI Flash for code to otherwise done board costs, I don’t know, $2 for the chip, $0.02 for capacitors and resistors, 2-3 days to redo the board, software… can I just make it a want item for v2.0?
3) why do I have to do it wireless? Can I just snatch a prototype from test batch, wire it to debugger and leave it on a desk? Do I really have to manage these keys, and why are you going to be signing it off for release if it’s not working?
Embedded devices are not like a Nintendo Switch, it’s like Switch Joy-Cons, or even buttons on Joy-Con sometimes. They are not like nail-top autonomous Pi calculation device. Admittedly, Nintendo update Joy-Con firmware sometimes, but very rarely, and they don’t make Switch playing kids wait for X button input to finish processing. The buttons are read, sent out, and received. It just makes no sense that adding drag to real-time computing this way would help a lot.
You do get credit for using the cheapest and lowest cost MCU for the task which directly depends on performance of the code. In case of battery operated devices it is even more important.
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.
However, I suspect that the company making the ad will just list the lowest possible salary in the posting to deter real applicants from applying, hence making the greencard applications smoother.
However, don't quote me on this, since this is just my very vague knowledge on how greencard applications work. Somebody else here who knows more about this topic, please chime in to let me know if this is true.
I suspect the target audience is more on the hobbyist/non embedded programmer side of things.
However, I heard of uPython being used in production deployments, though maybe not in millions of units.
(I'm working on DeviceScript)
Excellent tooling exists for you if your language is TypeScript, so maybe try putting TypeScript in more places.
I think the limitations for devicescript would probably also work for outputting reasonable amounts of 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.
I wtapped much of zephyr as well but that ones less used: https://github.com/embeddednim/nephyr
https://github.com/andrei-markeev/ts2c/
https://github.com/evanw/thinscript
If you aim for 32 bit microcontrollers then you can go with assemblyscript to wasm and then with wasm to C transpiller
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.
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)
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.
Cost cutting in high volume electronics is crazy.
Why the constant obsession to apply a technology designed for a specific purpose everywhere else, even when it doesn't make sense?
Not to say that's valid in this instance, but plenty of early VMs were entirely made to improve resource constrained hardware
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.
Unless you have a background in C/C++ already, most people can probably get up and running with something like this way, way faster.
Same problem for MicroPython. Same problem for LUA, same problem for any scripting language running on constrained MCU.
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.
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.
* 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.
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.
(26 May 2023) https://news.ycombinator.com/item?id=36079842
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."
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...
Though it also seems like it doesn’t use both of the LX7 cores:
> and at most one fiber runs at any given time
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's MakeCode project already provides something similar, via compilation to C++, for quite some time now.
Also MakeCode compiles to ARM machine code in the browser, not C++, which is one of the things that make it hard to port.
- 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.
