That is old…
These days “embedded” is used to mean any system without a WIMP interface.
Generally SoC running Linux.
I am old, too, but not an embedded developer. I was shocked to see that now I am an “embedded developer” for most uses of the term.
Don’t underestimate the strong urge of those “innovators“ to add a touch screen to everything with an MCU. Then you will get everything around you winking at you constantly with a WIMP interface.
That’s exactly the reason I designed Thing-App. One touchscreen on your phone is enough to build any arbitrarily complex machine.
Yup!
I've read through everything you've posted and I'm still not sure I understand the problem to be a Rust problem. You mention “write once, run everywhere” as a design goal. This was a promise of the Java runtime design, but it never quite delivered on that promise. The idea of write once, run everywhere is pretty much impossible. Even if you were to constrain the problem enough to make it work, you're going to end up with sub-optimal utilization of resources on many of your targets. Also, the USER never loses out if source code is available. Your design talks a lot about privacy and security and in my opinion, having source available, even if they never read it, is crucial to privacy and security in today's world. And finally, Rust’s ABI stability should not matter. If your goal is for the code to always be compilable, pick a compiler target, version control that compiler target, and document that is your target. If you ever decide to change it then you document that, too, and deal with whatever breaks. This is standard practice in embedded devices.
There is always a hard way and an easy way of doing things. And the hard way is very much a Rust problem:
- Hard way - One thread to schedule multiple Thing-App processes while each process is still under the illusion that it is the only process in the system, the process context is automatically handled by the scheduler, with maximum code sharing. For example, there is only one copy of the shared core library code in the flash memory.
- Easy way - A separate thread drives each Thing-App process. Each Thing-App code is a monolithic, dependency-free binary static library.
As for “run everywhere,“ we know what platforms the Thing-App will be running on. Those are big ARM CPU for Hub, and Cortex-M and RISC-V for MCUs. We can compile for each target and pack all compiled targets into the distribution package on the Thing-App store.
The reason we have to allow closed-source code is that I want more suppliers and consumers on the Thing-App store.
This and..
I think the complexity comes from the fact that an embedded platform is not the CPU only. It’s a CPU with peripherals like timers, ADCs, DACs, I2C, SPI, USART busses etc. built around it. At the end what makes the automatic lawn irrigation work is both the CPU and these peripherals working in harmony.
While the core architecture of the CPU remains more or less stable with every iteration by the vendor, the peripheral configurations from the MCU vendor may change both at a faster rate and more dramatically. Because it is also in the interest of MCU vendors to change peripheral configs frequently to keep themselves ahead of board and MCU counterfeiters. Keeping track of these changes is not a simple undertaking.
I wish you success in your endeavor. Even if it doesn’t become a huge hit, it will be great R&D for sure.
The devices can be abstracted and standardized. For example, see the Matter Data Model.
Thing-App is a pure application-level. For example, in the sprinkler example, a user inputs two zones to the Thing-App. The code only sees two on/off relays, each with a unique ID. The Thing-App only knows those two on/off relays, and there is a standard way to control on/off relays.
Thing-App doesn’t know anything else about the other devices or the network, etc. It doesn’t need to know, so it is not allowed to know for security reasons.
With a standard data model, five function calls can control anything. The same API may interact with devices locally or remotely. There are many benefits of local control, which is why we need to run Thing-Apps locally on MCUs. And the same code will also work running remotely on Hub through remote control.
You may have a point. With use of vendor SVD files as source of truth for example, a degree of automation can be achieved.
Libertas Thing-Apps run on top of Libertas OS, just like Android Apps run on top of Android OS.
Thing-Apps only deals with abstract devices and a few API, i.e., a very much application-layer environment. Thing-App developers only care about data exchange.
So like Linux, LibertasOS will bundle all possible IoT peripheral drivers as well as all permutations of peripheral configurations for all devices? Linux can do this because host resources are vast compared to Linux itself.
Current devices already did it. Search Amazon for Matter devices, switches, dimmers, thermostats, sensors, etc. Libertas OS is a thin layer on top. It may add a few dozen KB of flash memory to provide APIs to Libertas Thing-Apps.
As I said, once devices are abstracted and standardized, interaction is just exchanging structured data. Let me give you another example: a Thing-App uses an API to interact with a remote device through Libertas-OS; why would Libertas-OS bundle a peripheral driver of that remote device?
Another option might be wasm - I've seen work towards wasm on microcontrollers.
I also vaguely remember http://pigweed.dev being a sort of rtos that can run Rust along with other modules.
But regarding sharing source - I suspect you can solve that "problem" with legal contracts, and offer the compiling and linking as a service. You should be able to get a more compact binary than dynamically linking.
It is so great to meet so many like-minded. I did consider it as an option. In the Thing-App documentation, it is called "managed compiler service."
But I would rather not keep the source code. It is a huge liability. If we keep nothing, no one can steal anything from us. I don't want any data from anyone. That's the best way to keep everybody safe in the vicious world.
Since we can get machine code from Rust, there is really no point to use wasm. I think we can avoid using dynamic linking. The Hub manages all dynamic resources for the devices. The Hub can allocate the ROM/RAM sections for the Thing-App static library, perform static linking with generated ld script and remotely send code to the device to write to the flash, then execute.
The problem is, without a stable ABI, we can only use static lib. If the user runs two Thing-App tasks on the device, both code will be bloated with some common library code.