I have a good question when it comes to FreeRTOS.
I have looked through some of the source code, and I have noticed the source code is so readable.
Some of the source code for embedded systems which I have seen are very compressed to save space; therefore, they are hard to follow. Also I have seen this practice of “defining syntaxes” like #define FOR_ALL for(i=0; i<ARRAY_SIZE; i++), etc. which is just BS for someone reading the code.
How come FreeRTOS community has decided to go for clarity over size?
1 Like
I can’t speak for Richard Barry, the originator of the project, but based on his comments over the years, the compiler does a better job at optimising code than we mere mortals are.
Also, if one reduces the readability of the code, chances are that there will be bugs that will go unnoticed and fixing those will be difficult as the maintainer’s job is rendered that much more difficult for the unreadable code.
It also fits with MISRA C programming guidelines.
To put is differently: clear code is better than concise.
2 Likes
As was said, readable code is reliable code as you can more easily see the bugs.
Shorter source code also doesn’t necessarily take less memory, especially if done with macro tricks.
I disagree. Don’t try to read the code, better try to study FreeRTOS from its core. It’s a nightmare.
You might think the source code is readable because it has a lot of white spaces, but that doesn’t mean you can study the kernel to modify it or enhance it.
In the past I’ve tried several times to study it for some enhancings. Every time I’ve given up. The only one that can modify it is R. Barry (whom I consider a genius). BTW, I hate the FreeRTOS name conventions: what the heck means an ‘x’ in xTaskNotify() (for example)? It can mean anything!, so you need to jump on the documentation. So what was then the purpose of those ugly prefixes?
I love FreeRTOS, but it’s not the best software written ever. Do you want to read a very clean kernel? Look for and download (now it’s free) uc/OS II or III. It’s crystal clean.
Wow, I have just looked at uc/OS II source code, and its very good, thank you!
One thing to clarify, us/OS II and III may have freely available source, but it IS a commercial product, and needs to be licensed to be legally used. There are specific cases listed (like educational) that are granted a free license, but the code does need to be licensed.
FreeRTOS on the other hand, now used the MIT License which grants a perpetual right to use for basically any purpose. There is an option to buy a license if a company wants extra legal protections or dedicated support, but otherwise it is totally free to use.
(Prior to Version 10, it was licensed under a modified LGPL, meaning that if you changed FreeRTOS itself, you had to share those changes, but not the rest of your application)
For every person who has your opinion I will find an equal number with the opposite opinion. Within reason, style is subjective. The most important thing to me is not style, but consistency of style. A lot of the style used in FreeRTOS is a hang over from work I’ve done in safety critical applications.
The naming conventions are a hang over from days when tools, specifically editors, were not as smart as they are today and basically just text editors with no context. The lower case prefixes tell you the type of the variable or the return type. FreeRTOS runs on 8, 16, 32 and 64 bit devices, so over time most because ‘x’ meaning a non standard type (typically BaseType_t), so it sort of lost its purpose. The first word in the function name tells you which file the function is defined in. The style and naming conventions are documented on the website.
Hungarian notation Vs non Hungarian. Tabs Vs Spaces. How you format comment blocks. These discussions never end and are largely fruitless because really nobody is right and nobody is wrong.
1 Like
I guess you’re talking about the original license, but I think that’s obsolete. Recently the source code has been released under the Apache license (royalty-free for short).
I was aware of this change when I received a mail from a mail-list “The embedded muse 397” from the embedded guru Jack Ganssle. You can get the source code from the link inside the article:
µC/OS Goes Open Source
Most readers probably know of [Micrium], the company whose µC/OS RTOS and related products have been very popular in the industry. I’ve known Jean Labrosse, the founder, for decades and have long admired his company. And I’ve long admired the code base, which is incredibly clean. How clean? It is certifiable to numerous standards, including the rigorous avionics DO-178C.
Micrium was acquired by Silicon Labs a few years ago, but very recently that company has pretty much abandoned the Micrium product line. µC/OS-II and µC/OS-III and many of the other parts of their stack are now open source. Dozens of processor families are supported.
One of Micrium’s marketing strategies was to sell a number of well-written deeply-technical [books] about the products. I always liked the fact that some are tailored for particular processors, so a reader can immediately run example code on specific platforms. PDFs of these are now free.
Support for the product line is now available from [Weston Embedded Solutions] in the USA and [Embedded Office] in Germany.
[Validated Software] is one company that provides certification packages for safety-critical applications. In the avionics world that’s DO-178C, and the Micrium products are certifiable to level A, the most stringent. From their [website]: Ninety percent of the µC/OS Validation Suite is “pre-existing” and has been used for “previously certified” software. I presume that as long as users don’t monkey with the code this statement will remain valid.
And not monkeying with the code is a feature Weston Embedded seems to embrace. From their website: Cesium RTOS [is] a commercially licensed RTOS that is derived from Micrium’s uC/OS products and completely free from modification by open source contributors . An unusual statement in our times when open source has attained religious stature, but if certification to safety-critical standards is important, one doesn’t want every Tom, Dick and Jill changing things.
Rolando Ingles of Weston Embedded told me that Cesium is the Micrium RTOS stack. The company will continue to maintain that code and extend it as needed, while maintaining the clean code standards of the predecessor company. Micrium will be honoring support agreements till the end of the year. Customers will come to Weston Embedded or Embedded Office for licenses, support and consulting (e.g., creating new BSPs, ports, device drivers and the like). Interestingly, he says some customers have bought licenses instead of getting the open source code as they feel that approach is cheaper than getting OSS through their legal department.
This is a time of great change in the RTOS business. Amazon acquired [FreeRTOS]. Microsoft bought [Express Logic] (ThreadX and related components). The products are easier to use than the old days; SEGGER has a [demo] that can get a novice running their RTOS in under 5 minutes.
Do you need an RTOS? Not all projects do. But this is an area where careful up-front design is critical. In the very early 1980s I designed an instrument that had quite a few I/Os, figuring it would be easy enough to handle everything via polling and some interrupts. A combination of requirements growth and my poor planning meant that I eventually had to shoehorn an RTOS into the (now extant) code. That was a nightmare that bloated the schedule… and taught me the importance of good design.
I’m often asked how does one know when an RTOS is needed. There’s no generic answer, but if the system needs to run multiple independent activities, it’s time to consider adding one. An example: if a display needs to be updated at some rate, inputs monitored, communications is going on, an OS might be a good choice. Sure, one can handle these activities with a simple interrupt-driven design, but as the complexity grows that can get out of hand.
Some engineers avoid OSes because they worry about determinism. We know that under all the wrong conditions, like a perfect storm of interrupts, preemptive multitasking can fail to schedule all of the tasks. And multitasking can create problems with locks and priority inversion. These are legitimate concerns, though there are solutions to many of them.
Back in 2000 or so, I bought the uC/OS book and along the source code, I learned how operating systems work. But I never use it because of its restrictive license.
If you’re interested I can forward you the email so you get all the links (I had to remove all but one for this entry to be post).
Well, I pulled up their documentation page at https://doc.micrium.com/pages/viewpage.action?pageId=16879773 and https://doc.micrium.com/display/osiiidoc/Licensing+Policy and it still says that it is a licensed product.
Looking at their front page, I see the big announcement of it now being open source, and their parent company (Silicon Labs) dropping all direct support for the product, and referring you to 3rd parties for support.
We have used uC/OS III for one product and my experience with it was that it was clunkier than FreeRTOS (but part of that might have been the architecture of the system design the programmer adopted).
Did a bit of poking, it looks like uC/OS has the open source version on Git Hub, if you notice the link in the banner on the front page. All the code/documentation on site, is still under license (or at least hasn’t been updated).
The Micrium docs are out of date somewhat. The new (as of Feb 2020) open source Apache 2.0 licensing policy is described here: https://www.micrium.com/rtos/licensing/
The license info has also been updated 3 days ago for each of the uC products in SiLabs’ GitHub.