/*
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.3KiB
* 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
* 200,000 threads per second on a 72MHz STM32.
* The Context Switch takes 2.3 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.
*/