51–60 of 160 posts
Earlier quoted context omitted.
> 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.
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?
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.
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…
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…
Earlier quoted context omitted.
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?
Then you probably shouldn’t use this. It’s not for you, that’s cool, move on and use whatever you’re currently using.
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.
it's not C, so that's a great step towards making programming IoT more accessible.
Earlier quoted context omitted.
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…
The debuggability is also far better I expect, as a person who has spent hours tracing some crash deep in LwIP because of a bad flag or wrong interrupt priority.
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?
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…