WARNING: This site is getting prettier but it is still under construction.
So why would one roll his own RTOS when there are dozens, if not hundreds out there on the Internet? Mostly out of frustration.
If one searches for an RTOS on GitHub some 60 hits show up. The number of OS projects on the osdev.org Wiki and operating systems listed on Wikipedia is in the hundreds. So apparently writing a new OS isn't exactly rocket science. Which begs the question why is the basic OS kernel not a commodity?
If you are a carpenter and you use screws, or bolts and nuts to build your products you can go to your friendly neighborhood hardware store and buy what you need. You don't have to give details about your business to your supplier just to get a price quote. Neither does the manufacturer of your bolts and nuts attach arbitrary restriction on their use and force you to buy a new package of bolts to hold tables together, because you are supposed to use the previous bag only for making chairs
And I am reasonably certain that if anyone tried to explain to you that you have to buy bolts and nuts in packages that also include washers and O-rings that people who use bolts and nuts might need, and if you can't find a good use for them that is your problem, at the very least you would look for another supplier.
Yet the software industry operates on those principles, and people are so used to it that they don't even find it the least bit odd.
So my choices appear to be to accept this insanity, embrace someone else's science project OS, or roll my own. I have opted for the latter.
For various jobs I have ended up writing an OS kernel at least twice before. Now I have decided to implement one for myself that is truely free in the sense that it has no strings attached to it that would limit what I am allowed to do with it.
While writing an operating system requires investing actual work in the project, the feeling when you see that you now have enough functionality that can support some serious third party software such as a TCP/IP stack does give you the feeling that you have accomplished something.
When I have decided to start working on my own embedded OS core the goal was to have a minimalistic implementation of a multi-tasker that I can use for projects that many people would consider doing on bare metal without an OS, but which projects nevertheless would benefit from having some notion of multiple threads progressing at the same time.
In many aspects I have accepted limitations for the sake of simplicity.
Do I really need to be able to run an infinite number of tasks?
Embedded projects that I have worked on usually had around a dozen or so tasks and never needed more. So definitely there is a class of applications that don't need an infinite number of tasks to run simultaneously.
Interrupts happening during the processing of other interrupts?
Never actually needed them -- although I acknowledge that there can be situations when they come in handy. On the other hand your code should not linger long enough inside an ISR for it to matter.
Should memory and other resource management be part of an RTOS kernel?
I once again would say not necessarily. Really small embedded systems might not have any use for dynamic memory allocation, or have enough RAM to be worthwhile to do allocations in the first place. On bigger systems some form of malloc() and free() might come with the C libraries. A really rudimentary OS kernel should at least not be dependent on being able to do anything like a malloc() as it migth very well not be available on the target system and might not be possible to provide in a reasonable way.
Should all the features that the implementor of the OS can think of be included?
Probably not. One can invent an almost endless list of features as 'nice to have' -- some of them are even easy to implement. But then all those features need maintenance, and documentation, and if they cannot be conveniently removed from the the source tree they become part of the OS. If all the source code needs to be carefulyl reviewed and scrutinized, e.g. if the end product needs some sort of regulatory approval, then the unnnecessary features in a component, such as the RTOS, become a liability.
- Seriously, if I want a desktop OS in the product I can just run Linux on it. But sometimes something much, much smaller makes a lot more sense.
Last Modified: 2015-November-16.