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.
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.
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.
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.
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.
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.
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.
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.
And C vs assembly comparison is irrelevant. You are running assembly represented by C, but not interpreting C in assembly written VM.
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.
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.
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)