Hacker News new | past | comments | ask | show | jobs | submit login
How I ended up writing new real-time kernel (dmitryfrank.com)
157 points by qznc on Sept 21, 2015 | hide | past | favorite | 17 comments

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-Operatin...

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.

From the overview on Bitbucket (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.

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?

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.

For instance, more allocations necessary, extra pointer indirection, higher memory use, worse cache locality, needing the TN_ListItem* to perform list operations.

Twice the allocations? That can matter for performance reasons.

Or even more if the item is included in multiple lists.

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.

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.

They are correct that it's a typical clause in an EULA for the embedded industry.

It might turn out to be un-enforceable, but it would take a court case to determine that.

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.

Thank you very much for your feedback!

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

Thanks for the feedback!

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact