Dear Friends,
after some time of evaluation of software architecture for Multipilot32 I decide to put on it a Real Time Operating Systems.
Instead of choose FreeRtos or other clone . I found this interesting operating system that yet support HAL .
Above there's an introduction of Chibi OS , what do you think about ? My idea is to rewrite the lib of our Arducopter project using a professional approach with a Realtime Kernel on low level OS call.
I'm waiting your feedback :)
Chibios Introduction :
This document will help you understand what ChibiOS/RT has to offer in a world with so many similar products.
Why another RTOS:
The first question to be answered is: there was really the need for yet another RTOS? There are several reasons:
- The ChibiOS/RT ancestor has been created more than 15 years ago and while it had far less features than the current product it was complete and functioning. ChibiOS/RT is just a new (and silly) name given to something created when there were not many free RTOSs around (actually none, at least none in my knowledge, there was no widespread Internet at that time).
- When, after a while, I needed a RTOS again, none of the existing FOSS projects met my expectations or my ideas of how a RTOS should be. I decided that work on that old project was a better idea than contribute to, or fork, something else.
- I wanted another toy.
How is different ?
Well, there are some design choices that should be explained and contribute to make ChibiOS/RT a peculiar design. Nothing really new in itself but the whole is interesting.
Not Just a scheduler.
While the ChibiOS/RT kernel can be used even alone, see the General Architecture document, the RTOS also offers other subsystems:
- Support for startup and board initialization.
- An HAL abstracting many common device drivers, see the Features Matrix.
- Integration with other open source projects like File Systems, Networking Stacks etc.
ChibiOS/RT is meant to be a whole operating system not just a scheduler.
Static Design.
Everything in the kernel is static, nowhere memory is allocated or freed, there are three allocator subsystems but those are optional and not part of core OS, dynamic services are built as a layer on top of the fully static kernel.
Safety is something you design in, not something you can add later, using memory allocation in the kernel is unnecessary and relying on that is just asking for trouble.
No Internals structure and tables.
The kernel has no internal tables, there is nothing that must be configured at compile time or that can overflow at run time, no upper bounds, the internal structures are all dynamic even if all the objects are statically allocated.
No error Condition.
System APIs have no error conditions, all the previous points are finalized to this objective. Everything you can invoke in the kernel is designed to not fail unless you pass garbage as parameters, stray pointers for examples. The APIs are not slowed down by parameter checks, parameter checks (and consistency checks) do exist but only when the related debug switches are activated.
All the static core APIs always succeed if correct parameters are passed. Exception to this rule are the optional dynamic APIs that, of course, can report memory exhausted.
Very Simple API.
Each API function should have the parameters you would expect for that function and do just one thing with no options.
Fast and Compact.
Note, first “fast” then “compact”, the focus is on speed and execution efficiency and then on code size. This does not mean that the OS is large, the kernel size with all the subsystems activated weighs around 5.5KiB (STM32, Cortex-M3), see the section ”Performance and Testing Data” for more details about performance and footprint.
It would be possible to make something even smaller but:
- It would be pointless, it is already really small.
- I would not trade efficiency or features in order to save few bytes.
Test and Metric.
I think it is nice to know how an OS is tested and how it performs before committing to use it. Test results on all the supported platforms and performance metrics are included in each ChibiOS/RT release. The test code is released as well, all the included demos are capable of executing the test suite and the OS benchmarks. See the section ”Performance and Testing Data” for more details about performance and footprint.
Replies
I took an even closer look at the ChibiOS/RT docs and also the source code. Not saying others are better or worse, but among all the OS sources and docs I have seen - and I have seen lots (as an MVP I even had access to the Windows kernel) - ChibiOS/RT has a very clear design and code is well structured and commented/documented.
So thumbs up from me,
Stephan