/* ChibiOS/RT - Copyright (C) 2006-2007 Giovanni Di Sirio. This file is part of ChibiOS/RT. ChibiOS/RT is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. ChibiOS/RT is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see . */ /** * @page goals Project Goals *

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 was 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 RTOSes 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, not * even close (see below). I decided that work on that old project was * a better idea that contribute to, or fork, something else. * - I wanted another toy. * . *

Why is it 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: * *

Static design

* Everything in the kernel is static, nowhere memory is allocated or freed, * there are two allocator subsystems but those are options and not part of * core OS. Safety is something you design in, not something you can add later. * *

No tables, arrays or other fixed structures

* 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 conditions and no error checks

* All the 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 * as examples. The APIs are not slowed down by parameter checks, * parameter checks (and consistency checks) do exist but only when the * debug switch is activated.
* All the static core APIs always succeed if correct parameters are passed. * Exception to this are the optional allocators APIs that, of course, * can report memory exhausted. * *

Very simple APIs

* Each API 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 is around 5.2KiB * and can shrink down around to 1.2Kib in a minimal configuration * (STM32, Cortex-M3). It would be possible to make something even smaller but: * -# It would be pointless, it is already @a really small. * -# I would not trade efficiency or features in order to save few bytes. * . * About the "fast" part, the kernel is able to start/exit more than * 220,000 threads per second on a 72MHz STM32. * The Context Switch takes 1.41 microseconds on the same STM32. * *

Tests and metrics

* 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. */