From: Tim Wescott on 29 May 2010 14:09 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
|
Pages: 1 Prev: mplab linker problem - newbie problem Next: Fine, so what is a "complete" RTOS? |