The same could be said for MicroPython or CircuiyPython.

I suspect the target audience is more on the hobbyist/non embedded programmer side of things.

The thing is, if you want to poke at a device interactively, your options are either Forth or (if the system is beefy enough) one of these scripting language ports; tethered C interpreters are not precisely commonplace. And while I love Forth to bits, most people will probably go the scripting-language route.

A whole 8 bit computing generation was able to jump into computing thanks to scripting.

There are some differences, but broadly correct (eg., the program is precompiled and the experience is definitely the best in VSCode; plus of course different language).

However, I heard of uPython being used in production deployments, though maybe not in millions of units.

(I'm working on DeviceScript)

it's not C, so that's a great step towards making programming IoT more accessible.

Well that's valid as long as you don't get exception in underlying C driver. Now you are solving two possible problems - error in your script or error in the driver. Good luck debugging that without proper debugging probe.

That's been the argument against higher level languages since punch cards.

Sure, there may be problems, yet somehow the internet runs.

Coding in asm is fun, and a good skill to have for when you need it - but most of the time, you don't.

The problem is not higher level language. The problem is that you are essentially running dual-stack firmware with twice as complexity and twice as problems.

And C vs assembly comparison is irrelevant. You are running assembly represented by C, but not interpreting C in assembly written VM.

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 solved. Sure you can say that I can run scripts on my PC, but what if everything works on my PC, but the moment I will load it on the target, script will crash? Then without proper debugger I am screwed.

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/

I appreciate your engagement throughout this post, including how you are gently educating the naysayers.

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.

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.

LwIP (especially with Simcom’s SIM7000 via PPPoS underneath it) gives me PTSD. Even with decent JTAG debugging, it’s such a pain.

I think it's especially scary when most devkits come with it pre-integrated by the manufacturer, but the quality of that integration varied widely. My experience is nearly a decade out of date at this point, but when I was last going Cortex M3 stuff, I found that the integration of TI/Stellaris was excellent, and the integration on STM32 was one landmine after another— and the same held true for the USB stacks, even for stuff that should have been dirt simple like just emulating a serial port.

Yeah the STM32 dev kit (CubeMX etc) is all kinds of horrifying. ESP-IDF is better in some ways, worse in others. Its LwIP integration (esp_netif) is okay but has some interesting bugs you can hit. Like creating sockets leaking memory even after the socket is closed! Yay!

Yes.

Assuming you're working with a quality VM and drivers, development speed is also improved. A lot of low level details have already been worked out in the VM thus freeing the programmer to work at a higher level.

3 is a big one, I think. Using an interpreted language speeds up the development cycle to prototype, change, release, and iterate. And for some purposes it's fast and small enough, that the trade-off is worth it.

This makes a lot of sense. However, it makes me wonder how big is the new attack surface for remote upgrades/updates.

You need to implement a safe updater (with remote protocols) on VM level. And I guess you can never upgrade the VM itself, or if you can, it adds some extra complexity, or physical access.

There also need to be some kind of signature validation for every release, which means that device needs to perform some cryptographic operations and store at least tamper-proof public keys.

I can't really see how this is different from a native-code based device, especially one which is actually following good practice by not trusting what's in flash. Every stage of the boot chain still has to validate the next - there's just one more layer on top where the application is the runtime VM and it has to validate sub-applications / managed code.

>In embedded work, you don't get extra credit for being faster than necessary.

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.

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.

> In embedded work, you don't get extra credit for being faster than necessary.

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.

>"In embedded work, you don't get extra credit for being faster than necessary"

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.

I’m not sure if you get the controllers part of embedded microcontrollers. They’re not for time-independent deep thoughts, they are for controlling devices and peripherals in real time.

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.

I have a strong feeling that the TypeScript user base is mostly composed of people who are not good at picking up other types of programming languages. IMO that is the biggest reason for TypeScript. My experience is that the people that always propose TypeScript in every JavaScript projects they join, are not very likely to be able to write software in C++, Elixir, Go, JavaScript, etc.. They can only handle object oriented, type safe architecture.

TypeScript/Javascript are the modern PHP or Java of the world. It's something that people get pushed into it from school and their "first intro to programming", they often succeed through the meme of the language. But there's a subset that will struggle to actually be a "computer scientist" and pivot between languages and technologies in the long term.

I on the other hand started my "programming life" with C++ (because I was interested in a project written in C++) then I went to C# semi-professionally, if I was doing web it'd be with TS because of the tooling, also types help me organize my brain, and the escape hatch into YOLO land is very low in TS considering it's compiled into JS mostly, so the typesystem allows for "any" and such while still restricting things that aren't prototypes anymore.

Both C# and TS come "from the same author", so that might influence me a bit.

>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 wonder if many of these lowball salary job postings could just be companies applying for an employee's greencard through the PERM system. IIUC, for PERM, the applicant's employer is required to put out a job posting for at least 10 days to show nobody else can do the job their employee/greencard applicant does. The salary they list in the posting must be at least the minimum wage dictated by the Department of Labor for the role.

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.

In my experience, a firmware engineer contractor is much more expensive than a web contractor. But that's probably just a contractor supply/demand thing vs full-time.

TypeScript development on VScode is excellent (I'm told) so that would be a reason for this.

Excellent tooling exists for you if your language is TypeScript, so maybe try putting TypeScript in more places.

It most certainly is. I've tried a lot of development solutions over the years, and always find myself coming back to VSCode. The TypeScript support is amazing.

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.