5 ms·

How I ended up writing new real-time kernel

157 points by qznc 11y ago

hga 11y ago
From the overview on Bitbucket (https://bitbucket.org/dfrank/tneokernel https://bitbucket.org/dfrank/tneokernel): TNeo: a real-time kernel (RTOS) 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: ARM Cortex-M cores: Cortex-M0/M0+/M1/M3/M4/M4F (supported toolchains: GCC, Keil RealView, clang, IAR) Microchip: PIC32/PIC24/dsPIC 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. Plus the usual all caps disclaimer boilerplate.
roymurdock 11y ago
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.
- dimonomid 11y ago
  Thank you very much for your feedback!
dwwoelfel 11y ago
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. [1] http://www.amazon.com/Design-Implementation-FreeBSD-Operating-Edition/dp/0321968972 http://www.amazon.com/Design-Implementation-FreeBSD-Operatin...
- dimonomid 11y ago
  Thank you for such a positive feedback! 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.
jdmichal 11y ago
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: struct TN_ListItem { TN_ListItem * prev; TN_ListItem * next; void * data; } 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?
- AnimalMuppet 11y ago
  Twice the allocations? That can matter for performance reasons.
  - Gracana 11y ago
    Or even more if the item is included in multiple lists.
- gliptic 11y ago
  For instance, more allocations necessary, extra pointer indirection, higher memory use, worse cache locality, needing the TN_ListItem* to perform list operations.
- dimonomid 11y ago
  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. Both options are unacceptable.
blt 11y ago
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.
vmorgulis 11y ago
About FreeRTOS: > 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) It's quite abusive an probably not legal.
- dimonomid 11y ago
  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.
- aidenn0 11y ago
  They are correct that it's a typical clause in an EULA for the embedded industry.
- phire 11y ago
  It might turn out to be un-enforceable, but it would take a court case to determine that.
OJFord 11y ago
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"!
- dimonomid 11y ago
  Thanks for the feedback!

157 points by qznc 11y ago

hga 11y ago

From the overview on Bitbucket (https://bitbucket.org/dfrank/tneokernel https://bitbucket.org/dfrank/tneokernel): TNeo: a real-time kernel (RTOS) 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: ARM Cortex-M cores: Cortex-M0/M0+/M1/M3/M4/M4F (supported toolchains: GCC, Keil RealView, clang, IAR) Microchip: PIC32/PIC24/dsPIC 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. Plus the usual all caps disclaimer boilerplate.

roymurdock 11y ago

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.

dimonomid 11y ago
Thank you very much for your feedback!

dwwoelfel 11y ago

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. [1] http://www.amazon.com/Design-Implementation-FreeBSD-Operating-Edition/dp/0321968972 http://www.amazon.com/Design-Implementation-FreeBSD-Operatin...

dimonomid 11y ago
Thank you for such a positive feedback! 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.

jdmichal 11y ago

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: struct TN_ListItem { TN_ListItem * prev; TN_ListItem * next; void * data; } 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?

AnimalMuppet 11y ago
Twice the allocations? That can matter for performance reasons.
- Gracana 11y ago
  Or even more if the item is included in multiple lists.
gliptic 11y ago
For instance, more allocations necessary, extra pointer indirection, higher memory use, worse cache locality, needing the TN_ListItem* to perform list operations.
dimonomid 11y ago
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. Both options are unacceptable.

blt 11y ago

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.

vmorgulis 11y ago

About FreeRTOS: > 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) It's quite abusive an probably not legal.

dimonomid 11y ago
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.
aidenn0 11y ago
They are correct that it's a typical clause in an EULA for the embedded industry.
phire 11y ago
It might turn out to be un-enforceable, but it would take a court case to determine that.

OJFord 11y ago

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"!

dimonomid 11y ago
Thanks for the feedback!