
How I ended up writing a new real-time kernel (2015) - travisgriggs
https://dmitryfrank.com/articles/how_i_ended_up_writing_my_own_kernel
======
anitil
I had a great time following this a couple years ago. It inspired me to write
a tiny micro-kernel with pre-emtive multitasking. It was probably a bug-ridden
mess, but it was incredibly satisfying having a handful of threads printing
'Hello from thread #1', 'Hello from thread #2' etc.

~~~
wickerman
I had to code a small OS in C in third year of college and the main piece of
it was the scheduler. I remember my semaphore routines quite fondly actually.

~~~
anitil
What I wrote was nothing as advanced as that. Simple round-robin got it off
the ground and I don't think I ever looked at it again

------
fernly
Very readable article with the fun of first-person problem solving.

------
keithnz
I have done this before. I'm actually in the process right now of writing a
new version of an existing product on a new platform we have developed, and
after evaluating various off the shelf OS's, including RIOT and FreeRTOS, and
also considering a custom RTK, I have instead gone with a cooperative
lightweight actor based system with some special handling around interrupts.
It works quite nicely, and can easily be moved into a preemptive kernel if
needed at a later stage.

~~~
andyidsinga
I'm currently looking at FreeRTOS and mbed for a project on an STM32F07 mcu.
Anything you can share about either of those that made you decide against?

Also considering a super simple no-os fw loop with some light abstractions
because our real time constraints aren't very tight..

~~~
travisgriggs
I tried to use FreeRTOS on two projects. The first was an Atmel Xmega. The
second was an Atmel SamD21. FreeRTOS has its quirks, but it's pretty
straightforward and easy to understand. Unlike Zephyr and many of the current
slew of "IoT platforms", it doesn't try to be anything but a microkernel. Just
drop the C files in your sources, tweak the master defines file, and you're
good to go. Use whatever build system fits you best.

The one area (and this may be dated; my last attempt was nearly 2 years ago)
where FreeRTOS let us down was in tickless mode. I _think_ FreeRTOS's place of
primary use was originally FreeScale and automotive, where running tickfull
and powered all of the time makes sense. But we needed to be tickless and
sleep lots. There was a hook for doing that, but it was definitely "on your
own" and figure it what else you needed to tweak outside of the hook (like I
say, this may have improved of late).

I got distracted by RIOT because they spoke at ELC and I got it in my head
that it was more FOSS/open-sourcy than FreeRTOS. When I grew with frustrated
with RIOT, I stumbled on [https://www.osrtos.com](https://www.osrtos.com) and
gave TNEO a spin and was really happy with it.

I've only played briefly with mbed, but had the same frustration as many of
the others. It want's to be a full-stack end-to-end development solution. That
demos well, until you find you want to tweak the build process for some
reason. Or integrate it in your source control system some other way.

~~~
ploxiln
Prior to Amazon buying out FreeRTOS (along with its creator and maintainer)
and relicensing it to MIT, it was "GPL with exceptions". Clause 1 would be OK
if it left it at "through the FreeRTOS API interface", that's a thing that
projects have done to define a more practical boundary than "userspace |
kernel _or_ core system library" which the GPL uses on traditional operating
systems. (There was a GPL java replacement project that used a "classpath
exception" for the java standard library.) But the rest is odd and makes one
doubt that the GPL can really be modified this way and still be coherent.

Clause 1:

...

As a special exception, the copyright holder of FreeRTOS gives you permission
to link FreeRTOS with independent modules that communicate with FreeRTOS
solely through the FreeRTOS API interface, regardless of the license terms of
these independent modules, and to copy and distribute the resulting combined
work under terms of your choice, provided that

...

\+ The combined work is not itself an RTOS, scheduler, kernel or related
product.

\+ The independent modules add significant and primary functionality that is
unrelated to multitasking, intertask communication or intertask signalling -
and therefore do not merely extend the functionality already present in
FreeRTOS.

Clause 2:

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

~~~
loudmax
Those industry norms from clause 2 are pretty perverse. Sure banning the
publication of metrics will prevent the spread of inaccurate information. As a
side effect it will prevent the spread of accurate information, particularly
accurate information that reflects poorly on the project.

------
3xblah
Pardon the digression but I like the text-only "captcha". Don't see that too
often.

~~~
minitech
Doesn’t seem very accessible or effective when targeted, though.

~~~
3xblah
True.

More commonly, I see banner/figlet/etc. type fonts put into html apparently
for no purpose other than artistic reasons.

------
josemanuel
Why not use RTEMS ?

~~~
naasking
See the comments section of the article where author addresses this.

