89 lines
4.3 KiB
Plaintext
89 lines
4.3 KiB
Plaintext
/*
|
|
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 <http://www.gnu.org/licenses/>.
|
|
*/
|
|
|
|
/**
|
|
* @page goals Project Goals
|
|
* <h2>Another RTOS?</h2>
|
|
* The first question to be answered is: there was really the need for YET
|
|
* ANOTHER RTOS?<br>
|
|
* 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.
|
|
* .
|
|
* <h2>Why is it different?</h2>
|
|
* 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:
|
|
*
|
|
* <h3>Static design</h3>
|
|
* Everything in the kernel is static, nowhere memory is allocated or freed,
|
|
* there are three allocator subsystems but those are options and not part of
|
|
* core OS. Safety is something you design in, not something you can add later.
|
|
*
|
|
* <h3>No tables, arrays or other fixed structures</h3>
|
|
* 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.
|
|
*
|
|
* <h3>No error conditions and no error checks</h3>
|
|
* 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.<br>
|
|
* 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.
|
|
*
|
|
* <h3>Very simple APIs</h3>
|
|
* Each API should have the parameters you would expect for that function and
|
|
* do just one thing with no options.
|
|
*
|
|
* <h3>Fast and compact</h3>
|
|
* 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 <b>5.2KiB</b>
|
|
* and can shrink down around to <b>1.2Kib</b> 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
|
|
* <b>220,000 threads per second</b> on a 72MHz STM32.
|
|
* The Context Switch takes <b>1.41 microseconds</b> on the same STM32.
|
|
*
|
|
* <h3>Tests and metrics</h3>
|
|
* 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 @ref testsuite.
|
|
*/
|