Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DeviceScript – TypeScript for Tiny IoT Devices

github.com

Post reply on HN
Print view View original

91–100 of 160 posts

Re: DeviceScript – TypeScript for Tiny IoT Devices

#91

Post by mmoskal »

TheLoafOfBread wrote: post #82
claytongulick wrote: post #79

Earlier quoted context omitted.

Then I guess you'd better avoid any sort of embedded libc implementation too. Or fadecandy, or any external library. I've been through hell in embedded systems land debugging chipmaker-supplied C compiler problems. Should I just write it all in asm then? I've certainly made that choice for some projects. The point is, at some point you just want to get things done and you have to trust your tool chain.

You are completely missing my point. When I have C code and compile it, I will have opcodes which processor can run. All my bugs are going to happen only in C code and I can debug those using one debugging probe. When I have embedded scripting, then I have C code which represents my VM and I have also scripts. Then I am hunting for a bug in C code and script itself. I need two debugging stacks to get the problem solv…

DeviceScript comes with a source-level debugger for the VM code.

Indeed, if you add C code and that crashes it maybe harder to debug than a pure C system, however it wasn't my experience while developing DeviceScript - it was either clearly a bug in C that didn't really depend much on the bytecode, or an exception in DeviceScript which you debug just like in TypeScript.

We also support Jacdac [0] which makes it possible to put the C code on a different MCU, isolating the problem and adding traceability. (You can also run Jacdac server on the same MCU)

[0] https://microsoft.github.io/jacdac-docs/

Re: DeviceScript – TypeScript for Tiny IoT Devices

#92

Post by mmoskal »

Benjamin_Dobell wrote: post #9

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

Thank you! fix coming https://github.com/microsoft/devicescript/commit/a59e8aafce2...

Re: DeviceScript – TypeScript for Tiny IoT Devices

#93

Post by mmoskal »

jillesvangurp wrote: post #55

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.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#94

Post by mmoskal »

jononor wrote: post #41
geijoenr wrote: post #20

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?

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.

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

Re: DeviceScript – TypeScript for Tiny IoT Devices

#95

Post by mmoskal »

rkagerer wrote: post #12

No ESP32-S3? 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]

As for S3, PRs are welcome! :)

[0] https://microsoft.github.io/devicescript/developer/servers/a...

Re: DeviceScript – TypeScript for Tiny IoT Devices

#96

Post by mmoskal »

pjmlp wrote: post #38
ranguna wrote: post #2

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.

Why the wait? Microsoft's MakeCode project already provides something similar, via compilation to C++, for quite some time now.

We're the same people who founded MakeCode. DeviceScript has a very different target audience (professional TypeScript developers vs students), is easier to port to different architectures, is more tied into VSCode, and is more compatible with JavaScript semantics (though slower).

Also MakeCode compiles to ARM machine code in the browser, not C++, which is one of the things that make it hard to port.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#97

Post by ivxvm »

esrauch wrote: post #86
TOGoS wrote: post #72

Earlier quoted context omitted.

Yeah don't do that. :) Do this: interface Dog { typeName: "Dog"; woof():void } interface Cat { typeName: "Cat"; meow():void } function isDog(a:Dog|Cat) : a is Dog { return a.typeName == "Dog"; // Some casting may be required here } function f(a: Dog|Cat) { if (isDog(a)) a.woof(); else a.meow(); } let dogish : Dog = {typeName:"Dog", woof: ()=>{ console.out("Woof this is Dog")}}; f(dogish); The neat thing about TypeScr…

Sure, but opt-in nominal types that you describe is still something of a foot-gun that you have to be wary of since its easy to accidentally pass something that conforms to the structural type but violates whatever expectation. Like here's an example: type SpecificJsonBlob = {x: number}; function serialize(s: SpecificJsonBlob) { return JSON.stringify(s); } function addOneToX(s: SpecificJsonBlob) { s.x += 1 } [...] le…

Idk, I think it's extremely statistically rare coincidence for nominative typing to be a better default than structural. In other words, it's much more useful (by default) to have some function work on more types than be a little bit more type-safe for the exactly the type author had in mind when writing it. In my opinion, type-safety has diminishing returns and the most of its usefulness lies in trivial things, like passing a string instead of some object or array just as a typo, or writing a wrong field name when mapping one object to another, but nominative typing lies way beyond my imaginary line marking the zone when types become more of annoyance than help.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#98

Post by dromtrund »

jqpabc123 wrote: post #48
nicce wrote: post #17

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…

3) isn't really practical without some storage mechanism though. Sure, you can make a change that sits in ram until the next power cycle, but you could do that with firmware too if you plan for it. Whether you store the raw data in executable flash or in some external eeprom doesn't really change the workflow much.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#99

Post by AlotOfReading »

jononor wrote: post #26
iamflimflam1 wrote: post #23

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: https://microsoft.github.io/devicescript/api/clients https://microsoft.github.io/devicescript/api…

They should integrate with Zephyr OS, as they have a good generic sensor API, with tons of device drivers and platform support.

I wouldn't say zephyr has "tons" of drivers, except maybe in comparison to other RTOSes. It has a few drivers for each of the device types you might use, but you can't just buy random hardware without checking support the way you can with Linux. There's enough that you have examples for implementing your own drivers pretty easily though.

Re: DeviceScript – TypeScript for Tiny IoT Devices

#100

Post by samtho »

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.

Post reply on HN