Hacker News new | ask | show | jobs
by elcritch 633 days ago
Unfortunately migrating real-time stuff to Linux _doesn't_ necessarily reduce costs or simplify real-time development needs. I've been doing embedded development for 5+ years at a few companies and doing embedded Linux is still a slog. I prefer a good MCU running Nim or other modern language. Heck there's even MicroPython nowadays.

Especially for anything that needs to "just run" for multiple years. Linux means you must deal of the distro or something like Yocto or Buildroot. Both of which have major pain points.

1 comments

I would think the portability of, say, a Python application running on Linux is a nice benefit. Try switching from one MCU to a totally different one and you may have to start from scratch (e.g. try going from Microchip to STM.) Can you describe why embedded Linux is still a slog? And what do you think it would take for the issues to be addressed?
I thought we were talking about real-time applications, which I'm not sure Python is (even tuning the GC). But if we're talking about the difficulty of changing MCU families (remember stm32 are >1000 different chips) changing OS is also difficult, even changing from yocto to buildroot can also be a lot of pain on linux.
Doesn't Micropython already get you 95% of the way towards just running the same Python code on multiple MCUs?
I'm not sure, I've never used it. But I think the issue is that the number of MCUs that support micropython is very small.
MicroPython supports[1] PIC16 and SAMD21/SAMD51, STM32, ESP8266/ESP32 and more, but it also supports Zephyr as a target, and with it the platforms Zephyr supports[2].

So yeah not everything under the sun, but certainly not what I'd consider a "very small" number of MCUs.

Of course, support level varies among the platforms, but you're not going to be doing too fancy things in MicroPython I imagine.

[1]: https://github.com/micropython/micropython?tab=readme-ov-fil...

[2]: https://docs.zephyrproject.org/latest/boards/index.html