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.
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.
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.
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..
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 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.
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).
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.
I had a positive experience using FreeRTOS for a number of years, primarily on a series of STM32 parts - Cortex M4 etc.
I built our embedded platform on top of FreeRTOS - basically some nice APIs to help make everything be event driven. Millions of dollars and hundreds of thousands of lines of C later, it's the basis for a whole product family.
A sibling comment says something about tickless idle. It was a little while ago that I had to get it working, but I don't remember anything particularly painful about it - I think it was just a config option.
