4 ms·

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

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

jononor 3y ago
They should integrate with Zephyr OS, as they have a good generic sensor API, with tons of device drivers and platform support.
- AlotOfReading 3y ago
  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.
  - gwoplock 3y ago
    I agree with your driver assessment as someone who's used Zephyr quite a bit. If you're working with a new sensor, writing a new one is super straightforward. I don't have much experience picking sensor devices for embedded Linux, but I didn't think they had a ton of drivers for those types of devices. Bluetooth, networking, and SoCs, sure, but not so much for I2C/SPI sensors and displays and whatnot.
  - jononor 3y ago
    Tons might be stretching it. But to my knowledge there are not many alternatives for microcontrollers that have more? Hopefully one day it will be like Linux. At least they are trying to tackle the driver problem, unlike other most other RTOSes.
user_account 3y ago
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.
- Ins43b 3y ago
  I think having a strongly typed language is a great reason to have another interpreted language for IoT/embedded.
  - actionfromafar 3y ago
    Typescript is more of "firmly" typed than strongly, in my not so humble opinion. I guess it's beats C for IoT, but with Typescript it still feels like the S in IoT stands for Security.
    - mmoskal 3y ago
      The consequences of a type unsoundness in TypeScript are typically much more benign (an exception typically) than in C (a buffer overflow, arbitrary code execution, etc.). Also the application logic is more visible in TypeScript just due to it being higher-level - there isn't so much low-level detail (ever done JSON in C?) so less chance for a mistake.

jononor 3y ago

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

AlotOfReading 3y ago
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.
- gwoplock 3y ago
  I agree with your driver assessment as someone who's used Zephyr quite a bit. If you're working with a new sensor, writing a new one is super straightforward. I don't have much experience picking sensor devices for embedded Linux, but I didn't think they had a ton of drivers for those types of devices. Bluetooth, networking, and SoCs, sure, but not so much for I2C/SPI sensors and displays and whatnot.
- jononor 3y ago
  Tons might be stretching it. But to my knowledge there are not many alternatives for microcontrollers that have more? Hopefully one day it will be like Linux. At least they are trying to tackle the driver problem, unlike other most other RTOSes.

user_account 3y ago

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.

Ins43b 3y ago
I think having a strongly typed language is a great reason to have another interpreted language for IoT/embedded.
- actionfromafar 3y ago
  Typescript is more of "firmly" typed than strongly, in my not so humble opinion. I guess it's beats C for IoT, but with Typescript it still feels like the S in IoT stands for Security.
  - mmoskal 3y ago
    The consequences of a type unsoundness in TypeScript are typically much more benign (an exception typically) than in C (a buffer overflow, arbitrary code execution, etc.). Also the application logic is more visible in TypeScript just due to it being higher-level - there isn't so much low-level detail (ever done JSON in C?) so less chance for a mistake.