That was a great writeup, thanks. The author has a real talent for writing engaging explanations.
I've been making my way through The Design and Implementation of the FreeBSD operating System[1], which is a bit denser and more formal. It was nice to read about some of the same ideas in a different implementation. I'd recommend the book to anybody who enjoyed the post.
And thanks for sharing the book, I'll probably get to it. I've read a couple of books on Linux Kernel before writing TNeo, but haven't read anything on FreeBSD yet.
TNeo is a compact and fast real-time kernel for embedded 32/16 bits microprocessors. It performs a preemptive priority-based scheduling and a round-robin scheduling for the tasks with identical priority.
TNeo was born as a thorough review and re-implementation of TNKernel v2.7. The new kernel has well-formed code, inherited bugs are fixed as well as new features being added, it is well documented and tested carefully with unit-tests.
Currently it is available for the following architectures:
Like TNKernel, it has a custom but very simple FOSS license:
Permission to use, copy, modify, and distribute this software in source and binary
forms and its documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting documentation.
Honest question: What's the value, if any, of using intrusive linked lists in this context? That is, I would have handled linked lists as something like:
I can immediately see that each TN_ListItem would take up an extra word of memory in order to store the pointer to the data. Is that the main crux of the issue, or is there something more?
TNeo never allocates memory from heap: it only operates on objects that are given as parameters to some system services. And this is really good: a great deal of embedded systems don't use heap at all (since heap behaviour is not deterministic enough).
So, for example, when task is waiting for some mutex, this task is added to the list of waiting tasks of this mutex, and this operation is O(1), that is, it is always done in constant time.
With the implementation you proposed, we have two options:
1) When adding new object to some linked list, TNeo should internally allocate this list item from heap (or from some preallocated pool);
2) The client should allocate TN_ListItem-s manually (in whatever way), and provide it to any system service that may need it.
For instance, more allocations necessary, extra pointer indirection, higher memory use, worse cache locality, needing the TN_ListItem* to perform list operations.
> First, I don't like their policy: the license states that it's forbidden to compare FreeRTOS to any other kernel! (...)
> FreeRTOS may not be used for any competitive or comparative purpose, including the publication of any form of run time or compile time metric, without the express permission of Real Time Engineers Ltd. (this is the norm within the industry and is intended to ensure information accuracy)
Agreed. I'm not a lawyer, so not sure about legality, but since this clause is persisted for so long in their license, it seems they have no problems with it.
Really thorough and interesting write-up. I don't have much to add, but wanted to express my admiration for the author's grit and perseverance on seeing a problem through to its end.
This is well worth a thorough read (I admit at this point I've only properly read the intro and a couple of (the most) interesting looking sections; skimmed the rest) - an entertaining style and very informative.
Love the perseverance that essentially took you from "this kernel has a bug somewhere.." to "I wrote a kernel"!
This was a really good article. I've never used a RTOS, but I'm getting into robotics and I'll keep TNeo in mind if I ever need one. I'm using bigger ARM systems capable of running Linux but I'm curious about possible performance gains from using embedded programming style on these powerful machines.
I've been making my way through The Design and Implementation of the FreeBSD operating System[1], which is a bit denser and more formal. It was nice to read about some of the same ideas in a different implementation. I'd recommend the book to anybody who enjoyed the post.
[1] http://www.amazon.com/Design-Implementation-FreeBSD-Operatin...