It's a 5 gallon pail of compute which is all used up in OS overhead so you can do a cup of work.
If the job were that small that it fits in the remainder, then you could and should have just used 1 cent hardware instead of 1 dollar hardware.
As a reality check: MicroPython can run in 16 KB of RAM; a typical development board has 192 KB. µCLinux requires at least 4 - 8 MB of RAM just to boot up, and recommends 32 MB for a "serious product" [1].
> Linux has solid network, WiFi, Bluetooth stacks and a rich box of tools that might be very nice to tap into without requiring something as big as an RPi.
I would absolutely not count on any of those tools being available and functional in a µCLinux environment.
[1]: https://www.emcraft.com/imxrt1050-evk-board/what-is-minimal-...
I'm not convinced that's true. All of the microcontroller tooling I've seen has been built around RTOS development; I've never seen anything comparable for µCLinux.
That's all worth it to have an application processor that can run your Python/Java app. It's probably worth it to have a consistent operating system across multiple devices.
Would you have many of those benefits if you were using Linux on a micro though? I can't imagine much 3rd party software would work reliably given the tiny amount of RAM. You'd basically just be using it as a task scheduler and wrapper over drivers. You could get most of the benefits by using an RTOS with a memory allocator.
At some point, it might start making sense to level up the OS to (nommu) Linux on these devices. When the applications get complex enough, people find themselves wanting a full blown network stack, full featured storage/file systems that are aligned with non-embedded systems, regular shells, POSIX userland, etc.
All of the architectures I have in mind are 32 bit and "nommu"[1]: Cortex-R52/F, Infineon TriCore, Renesas RH850, NXP Power e200. Then you have RISC-V MCU Cambrian Explosion underway.
I qualify all this with mays and mights: it hasn't happened yet. I'm just careful not to discount the possibly of a <50 mAh RP Pico 3 booting uLinux, running python and serving web pages being a big hit.
[1] They all have various "partition" schemes to isolate banks of RAM for security, reliability, etc., but real MMUs are not offered.
When you have a fleet of embedded devices you want pre-compiled disk images, repeatable builds, read only filesystems, immutable state (apart from small and well controlled partitions), easy atomic updates, relatively small updates (often devices are at the other end of a very slow cell connection) and a very clear picture of what is running on every device in your fleet.
Linux can do all that, but it's not the paradigm that most distros take. Pretty much the entire Linux world is built around mutable systems which update in place. So you're left to manage it yourself. If you want to do it yourself, you end up in the hacky fragile world of Yocto.
Compared to that, using an RTOS or application framework like Zephyr is fairly easy - at the expense of app development time, you just need to worry about getting a fairly small compiled binary onto your device.
I do agree that there's some really powerful parts available which would benefit from the shared drivers and consistent syscalls a standardised operating system offers. But building and maintaining a Linux system for any part isn't a simple undertaking either - and so the complexity of that needs to be considered in total development time.
Linux is too unorthogonal for them.
What's missing? What would it take to make a plain RTOS that's as easy to develop on/for/with as Linux?
