I am always a little surprised by efforts like these coming from big companies. There have been multiple efforts in the past to put languages meant for the web on small footprint devices - especially JavaScript.
- Tessel (closed down, domain used to be tessel.io)
Note that some of these projects are over a decade old! Maybe I am the "old man yelling at the cloud" meme, but I don't see embedded developers who have to maintain a project for many many years, using a programming language that changes often.
It's obviously exaggerated and reductive, but you have to admit that not knowing how to use React properly is massively prevalent in frontend, let alone being able to recognize _when_ to use React.
Most FE engineers I know have a very deep understanding of react’s inter workings. It’s the full stack engineers that think it’s JS with extra HTML sauce and call it a day.
>with thousand page data sheets and programming manuals.
Why aren't those just a library? There is no way everyone deplicates the same work for interfacing with a chip for every single project that wants to use it.
There are plenty of libraries: from low level hardware abstraction layers to high level libraries like you'd find in the Arduino ecosystem. Those closer to the former (the HALs) require more understanding thus more reading, the latter expose less of the power of the chip because they target the least common denominator.
However, when you're making a mass produced piece of hardware with a $10 BOM cost and it turns out that you can save even 25 cents by using 90% of the power of a cheap chip instead of 5% of the power of an expensive chip, you're going to have to dive down into the documentation to figure out how to get every last ounce of processing power out of the cheaper chip.
That usually means exploiting the unique configuration of peripherals on a chip which can't be cleanly abstracted away by a software library. My first few projects, for example, I had to work around silicon errata in the family of chips the projects had chosen: STM32F4s couldn't run both DMA channels simultaneously at max speed when outputting to different peripherals. I wouldn't have been able to figure out what's going wrong at any level of abstraction without reading the documentation.
That's why I'm now in frontend instead of embedded.
There are many libraries, but the peripherals on modern microcontrollers are wildly configurable and the odds of any particular library supporting every single mode possible is essentially nil. And even if it did, then the library documentation would approach the chip documentation in terms of complexity.
I work in an investment bank that builds, operates and sells solar parks, and while the main builk of the work we do in the development department is in the fields of finance and asset management we do sometimes work with the solar inverters and similar. Being a non-tech enterprise means we're a rather small IT department in a large company that doesn't really care about tech beyond it working, as a result we've adopted Typescript as our "main" language. I've still build stuff in C and Rust, and our ML/AI employees do some of the work with Python, but over all we tend to use Typescript when and where we can because it's easier for our developers to switch and support each others if we work in the same language.
If we can use a Typescript subset maintained by Microsoft on the embedded devices at the solar plants, it'll be a absolutely amazing. Regardless of what came before.
Don't get me wrong. I wouldn't mind if something different took over. In many ways it would be much easier for us if we could do everything in Rust, but I don't think anyone in our team believe we'll see a realistic alternative to JavaScript on the frontend in our careers, so well...
I see things like MicroPython as a nice tool for prototyping hardware side rapidly (if you just need to test some SPI/I2C stuff in more complex way than i2c interface allows) and for projects simple enough that you don't ever will use most of the CPU and can afford to spend $ for wasted RAM/Flash.
Like, you just want to flip some bits based on some inputs in as simple way as possible.
But then eh, Arduino is easy enough for same thing...
I'm functionally oriented and being able to use TS instead of Arduino would be a blessing in this regard especially. I like using TS for functional coding because it forces me to really define my input/output types and helps with composability.
these tiny languages for MCU by design are not for 'significant complexity" to start with, even Lua might be too large and complex for "tiny iot devices".
Other comments have put better than I could, but I'll add that what people call ecosystems nowadays is completely unthinkable in embedded. Sometimes you have critical applications and you bet you need to certify every single line of code that goes into your application. Small embedded devices are more geared towards engineering than other kinds of development, and in my opinion that's why applications work well, in comparison with the mess we have in the web nowadays, for example.
Nicer from which side? Not OP, but I do like modern languages and great type systems - I’ll be the first to say that TypeScript is fantastic and maybe one of my favorite typed languages.
However, embedding Lua and writing bindings for it is really easy to do. The entire thing fits in a nice, neat single directory of a few ANSI-stone-age-C files and “Just Works”. You can drop it into your codebase, write a couple of simple bindings and be off to the races in no time. And you can easily fit its world model into the model of your application. Lua’s simplicity makes it a very, very powerful tool.
Ecosystems are as much a burden in embedded development as they are a blessing. Either you put in the time to support much of it across all your Tier 1 platforms or you punt on the problem, defeating the purpose of using a language with an ecosystem in the first place.
Take Javascript, for example. Which APIs are you actually committing to support? Are you going to support the Date class? BigInt extension? Node's fs, path, and crypto libraries? The browser's local storage, indexed DB, and other high level APIs? What about setTimeout and setInterval? Or are you only supporting pure-JS libraries, forcing the user to do a manual review of each dependency they consider?
A lot of microcontrollers - probably the vast majority in circulation - wouldn't have the ROM to even support most of those APIs, if they made any sense on an MCU to begin with. Look at MicroPython to see the kind of tradeoffs they have to make - it isn't pretty.
JavaScript is the most common language for building interfaces and being event-driven. These two aspects make it uniquely suited for hardware applications.
But even as a JavaScript (and specifically not TypeScript) zealot, I cannot get behind JavaScript on hardware. The reason we use C or C++ is specifically the control over the very limited memory and anything requiring a runtime or manages it’s own memory (a la garbage collection) is a non-starter. Firmware is written once and seldom updated. A node.js app is not a bad way to handle the server-side component on IoT given it’s event driven nature and access to low level constructs.
What do you consider by "very limited memory?"
The processor I generally use for my hobby projects has 16M Flash and 4M RAM. This isn't the 80's.
> Firmware is written once and seldom updated
Not these days where everything must have an App as an alternate frontend. Device Firmware Update was such a frequent request that we just made it a fixed-cost line item on our quotation forms when I worked at an engineering services company. Projects where the customer didn't want DFU were far rarer than the ones that did.
My most recent project uses an STM32F030C8 which has 64Kb of flash and 8Kb of SRAM. This is actually a beefier STM32 than I usually go for but was cheaper and more available at the time of the design.
I didn’t say it was never updated. Every IoT project or company I’ve worked on or with has the ability to update firmware and a lot of development effort goes into making sure that can happen. I have not worked at any place that pushed more updates per year than I can count on a single hand. Everything goes through, often manual, integration testing (ad nauseum in some cases), and field testing before it’s even considered as a release candidate. Compare this to release cadence of a CI driven development team for the web and server applications it connects to that deploys sometimes multiple times per day.
OK. My professional projects tend to be very large, so an 'F030 would be rather small. One of my current projects is based on an STM32F769, although I think we're using the smaller 1Mb Flash version.
DFU shouldn't get used a lot, I agree, but when it's needed it's a lifesaver.
Not to forget Java ME (or whatever it is currently called). I'd argue that it is by far the most successful of all these failed attempts because it still is on many (maybe most even?) smartcards.
- Tessel (closed down, domain used to be tessel.io)
- Toit Lang: https://toitlang.org/
- Moddable: https://www.moddable.com/
- Espruino: http://www.espruino.com/
- mBed tried it too: https://os.mbed.com/javascript-on-mbed/
- https://github.com/coder-mike/microvium
I am sure I am missing a few here..
Note that some of these projects are over a decade old! Maybe I am the "old man yelling at the cloud" meme, but I don't see embedded developers who have to maintain a project for many many years, using a programming language that changes often.