From: Tim Wescott on
I pontificated by saying that a complete RTOS should have both binary
and counting semaphores, and someone called me on it by asking just what
a "complete" RTOS is.

I realized that my definition of a "complete" RTOS is pretty fuzzy --
mostly a mismash of every feature that I've ever wanted to use in an
RTOS, with none of the features that I didn't want to use. This is
ironic, because I also made a snide comment about RTOS vendors being
self-centered.

I know what the minimum set of features I want in an RTOS -- basically a
prioritizing scheduler with deterministic performance, that allows tasks
to be started under the programmer's control from software entities
outside of the task. This gives you all the tools you need to fire off
tasks from ISRs or other tasks, to block on resources, pass messages, etc.

But what is a "complete" RTOS then? And if there is one, does anyone
want it? Is a "complete" RTOS just like a CISC instruction set, wasting
code space on features that one may never use, just so a vendor can crow
about it being "all there"?

And do you think my "minimum necessary" RTOS really includes everything
you need? Or do you think that it's just not functional until you can
pass messages and have Bertie Bott's Every Flavor Flag and Ethernet and
USB and a hard drive and cotton candy on a stick?

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com