Hacker News Reader

Comment by TickleSteve | Hacker News Reader

POSIX APIs are typically not appropriate for embedded systems.

For example filesystems. Filesystems are not generally applicable for single-purpose embedded systems. You're never going to need textual filenames, opening and closing file handles, etc. All that is just a waste, typically you just want to store your data to a log. This is much more appropriately stored in a simple circular buffer on FLASH without the overhead and non-determinacy of a filesytem.

Also, processes. These should be static. You typically never ever exit a task/thread on an embedded system.

Resets are a way of life. You have to acknowledge them in your design and error handling takes advantage of this.

I would not take POSIX compliance for a system like this as a plus point.

View on HN

> POSIX APIs are typically not appropriate for embedded systems.

This is a very broad brush. My Embedded Linux system makes amazingly good use of Linux and its Posix APIs. It’s also way to big to be the target of RIOT, so let’s talk about it’s 3 other embedded MCUs.

> Filesystems are not generally applicatble...You’re never going to need textual filenames

Really? Because I always enjoy talking to my cell radio doing AT+CMOGS=257,FFFFFF^1. That’s open file 257 and write FF.

Maintenance, debugging and robuestness of embedded systems is frequently overlooked. It allows not only a single dev, but a team to work, debug and release a system is a big deal. Embedded systems, esepcially those logging data, holding SSL certs, config data can very much use a filesystem. None of this has to be complex JFFS2 FS.

For example, if it’s an IoT, how do you plan to OTA it without good storage management?

> I would not take POSIX compliance for a system like this as a plus point

As a hirring manager anything that opens my pool of candidates is useful. Teaching someone a whole new environment is a big deal. If there’s similar concept and tools this ia big plus.^2

——-

1) ok, I can’t remember the right AT command or the right file number, but serisouly how did this make it into a public API in 2019?

2) Mostly true. If it’s too close that it’s almost the same, but not due a laundry list of weird exceptions I’ll skip it. Micropython is my example here, it’s like really close to python, may too close but too different. There’s lots of other embeddedable languages that aren’t too close but weird.

(Quick reply)

- RIOT is obviously targetted at microcontroller-based systems (not Linux level).

- AT commands... you can't use modems in general as a good example of anything. Thes software running on those things tend to be terrible.

- Good storage management != filesystem. you can simply allocate a rotating circular buffer in FLASH with CRCd blocks. This is a simple mechanism that gives you both bad-block-management and wear-levelling in one trivial mechanism. No filenames in sight! ;o)

- Hiring... There is a lot more to embedded systems than "Can they use the API". All RTOSs use similar APIs, thats never been an issue.

Agree with TickleSteve; there are file system essential options which may work out of the box for you, or at least provide a nice framework for what you need.

The microcontroller landscape is shifting rapidly. I think many of the things you've mentioned - no dynamic tasks, no filesystem, etc - are appropriate for some devices and some software but not all.

MCUs today are pushing the boundary on performance. We'll see GHz Cortex-M7 chips (already 600MHz+ today) running an RTOS in the near future, with external DRAM and flash. Users rightly want to push a LOT of functionality on them and that comes with advanced OS usage, including dynamic memory and threading. The developers using these systems are increasingly coming from an embedded Linux world as the performance line blurs, and POSIX is familiar.

Don't know why you got downvoted - this is a highly informed comment. The embedded systems landscape has been shifting rapidly since the introduction of the Cortex M0 about 10 years ago, and continues to do so with the hardware you mentioned, and will continue to into the foreseeable future. Perhaps what we need here is a redefining of the term "embedded system," or if nomenclature purists are against that, a new term altogether to encompass the systems you describe. Regardless of nomenclature flame wars, it's an exciting time to be involved with embedd... erm... the microcontroller world as it evolves at an unprecedented pace.

The higher end of microcontrollers are getting affordable, true.

This does not change the fact that a smaller, less capable uC will always be cheaper.

Embedded system designs are typically cost-driven, hence cheaper (and therefore resource-constrained) devices will always be a fact of embedded-life, no matter how "powerful" uC become.

Smaller uCs will also consume less power which is another important consideration.

Replied to your comment below as well, but will reiterate my primary point here,

You seem to be conflating embedded systems with safety-critical systems. There are plenty of embedded systems that are neither safety critical nor single-purpose. Also, plenty of non safety-critical embedded systems use microcontrollers that don't have the resources (RAM) to run Linux effectively (even MMU-less Linux) but could benefit from dynamic kernel capabilities like dynamic loading and unloading of drivers for hot-plugging events to support external hardware/accessories.

No, there is a large gulf between making robust, simple embedded software and safety-critical systems, I've done both sides of that equation.

Accepted general practice for (non-safety-critical) embedded software is to avoid dynamic behaviour wherever you find it.

This increases robustness and makes your code a lot simpler while giving you confidence you've handled your worst-case.

If you're not doing that, you're trying to do desktop-software on an embedded system.

Reply on news.ycombinator.com