andreika-git
/
ChibiOS
mirror of https://github.com/andreika-git/ChibiOS.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@753 35acf78f-673a-0410-8e92-d51de3d6d3f4

This commit is contained in:
gdisirio 2009-02-11 21:05:12 +00:00
parent 50bebb2976
commit 8486b10c8f
2 changed files with 31 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
docs/ch.txt
View File

@ -29,31 +29,24 @@
* Source <a href="http://en.wikipedia.org/wiki/Chibi" target="_blank">Wikipedia</a>. * Source <a href="http://en.wikipedia.org/wiki/Chibi" target="_blank">Wikipedia</a>.
* *
* <h2>Features</h2> * <h2>Features</h2>
* - Free software, GPL3 licensed. * - Free software, GPL3 licensed. Stable releases include a exception clause
* to the GPL.
* - Designed for realtime applications. * - Designed for realtime applications.
* - Easily portable. * - Easily portable.
* - Mixed programming model:
* - Synchronous, using semaphores/mutexes/condvars and/or messages.
* - Asynchronous, using event sources.
* - Mix of the above models, multiple threads listening to multiple event
* sources while serving message queues.
* - PC simulator target included, the development can be done on the PC
* using MinGW.<br>
* Timers, I/O channels and other HW resources are simulated in a
* Win32 process and the application code does not need to be aware of it.
* MinGW demo available.
* - Preemptive scheduling. * - Preemptive scheduling.
* - 128 priority levels. * - 128 priority levels. Multiple threads at the same priority level allowed.
* - Multiple threads at the same priority level allowed.
* - Round robin scheduling for threads at the same priority level. * - Round robin scheduling for threads at the same priority level.
* - Offers threads, virtual timers, semaphores, mutexes, condvars, * - Offers threads, virtual timers, semaphores, mutexes, condvars,
* event flags, messages, I/O queues. * event flags, messages, I/O queues.
* - No static setup at compile time, there is no need to configure a maximum * - No static setup at compile time, there is no need to configure a maximum
* number of all the above objects. * number of all the above objects.
* - PC simulator target included, the development can be done on the PC
* using MinGW.<br>
* Timers, I/O channels and other HW resources are simulated in a
* Win32 process and the application code does not need to be aware of it.
* MinGW demo available.
* - No *need* for a memory allocator, all the kernel structures are static * - No *need* for a memory allocator, all the kernel structures are static
* and declaratively allocated. * and declaratively allocated.
* - Threads, Semaphores, Event Sources, Virtual Timers creation/deletion at
* runtime.
* - Optional, thread safe, Heap Allocator subsystem. * - Optional, thread safe, Heap Allocator subsystem.
* - Optional, thread safe, Memory Pools Allocator subsystem. * - Optional, thread safe, Memory Pools Allocator subsystem.
* - Blocking and non blocking I/O channels with timeout and events generation * - Blocking and non blocking I/O channels with timeout and events generation
@ -61,8 +54,6 @@
* - Minimal system requirements: about 8KiB ROM with all options enabled and * - Minimal system requirements: about 8KiB ROM with all options enabled and
* speed optimizations on. The size can shrink under 2KiB by disabling the * speed optimizations on. The size can shrink under 2KiB by disabling the
* the unused subsystems and optimizing for size. * the unused subsystems and optimizing for size.
* - Small memory footprint, unused subsystems can be excluded by the
* memory image.
* - Almost totally written in C with little ASM code required for ports. * - Almost totally written in C with little ASM code required for ports.
* . * .
* <h2>Related pages</h2> * <h2>Related pages</h2>

43
docs/src/goals.dox
View File

@ -23,7 +23,7 @@
* <h2>Another RTOS?</h2> * <h2>Another RTOS?</h2>
* The first question to be answered is: there was really the need for YET * The first question to be answered is: there was really the need for YET
* ANOTHER RTOS?<br> * ANOTHER RTOS?<br>
* My answer is yes because various reasons: * There are several reasons:
* - The ChibiOS/RT ancestor was created more than 15 years ago and while it * - 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 * had far less features than the current product it was complete and
* functioning. ChibiOS/RT is just a new (and silly) name given to * functioning. ChibiOS/RT is just a new (and silly) name given to
@ -37,45 +37,48 @@
* - I wanted another toy. * - I wanted another toy.
* . * .
* <h2>Why is it different?</h2> * <h2>Why is it different?</h2>
* In itself it implements ideas already seen in other projects but never * Well, there are some design choices that should be explained and contribute
* all together in a single FOSS project. There are some basic choices in * to make ChibiOS/RT a peculiar design. Nothing really new by itself but
* ChibiOS/RT (mostly derived by its ancestor): * the whole is interesting:
* *
* <h3>Static design</h3> * <h3>Static design</h3>
* Everything in the kernel is static, nowhere memory is allocated or freed, * 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 * 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. * core OS. Safety is something you design in, not something you can add later.
* *
* <h3>No fixed size tables or structures</h3> * <h3>No tables or other fixed structures</h3>
* No tables to configure, no arrays that can be filled and overflow at * The kernel has no internal tables, there is nothing that must be configured
* runtime. Everything without practical upper bounds (except for resource * at design time or that can overflow at run time. No upper bounds, the
* limits and numerical upper bounds of course). * internal structures are all dynamic even if all the objects are statically
* allocated. Things that are not there cannot go wrong and take no space.
* *
* <h3>No error conditions and no error checks</h3> * <h3>No error conditions and no error checks</h3>
* All the API should not have error conditions, all the previous points are * 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 * finalized to this objective. Everything you can invoke in the kernel is
* designed to not fail unless you pass garbage as parameters, stray pointers * designed to not fail unless you pass garbage as parameters, stray pointers
* or such. Also the APIs are not slowed down by error checks, error checks * as examples. The APIs are not slowed down by parameter checks,
* exists but only when the debug switch is activated.<br> * parameter checks (and consistency checks) do exists but only when the
* debug switch is activated.<br>
* All the static core APIs always succeed if correct parameters are passed. * All the static core APIs always succeed if correct parameters are passed.
* *
* <h3>Very simple APIs</h3> * <h3>Very simple APIs</h3>
* Every API should have the parameters you would expect for that function, no * Every API should have the parameters you would expect for that function, no
* more no less. Each API should do a single thing with no options. * more no less. Each API does a single thing with no options.
* *
* <h3>Damn fast and compact</h3> * <h3>Fast and compact</h3>
* Note first "fast" then "compact", the focus is on speed and execution * Note first "fast" then "compact", the focus is on speed and execution
* efficiency rather than code size. This does not mean it is large, the OS * efficiency rather than code size. This does not mean it is large, the OS
* with all the subsystems activated is well below 8KiB (32bit ARM code, the * size with all the subsystems activated is well below 8KiB (32bit ARM code,
* least space efficient) and can shrink down below 2KiB. It would be * the least space efficient) and can shrink down below 2KiB. It would be
* possible to make something smaller but: * possible to make something smaller but:
* -# It would be pointless, it @a is already small. * -# It would be pointless, it is already @a really small.
* -# I would not sacrifice efficiency or features in order to save few bytes. * -# I would not sacrifice efficiency or features in order to save few bytes.
* . * .
* About the "fast" part, it is able to start/wait/exit more than <b>200,000 * About the "fast" part, the kernel is able to start/exit more than
* threads per second</b> on a 72MHz STM32 (Cortex-M3). The Context Switch just * <b>200,000 threads per second</b> on a 72MHz STM32 (Cortex-M3).
* takes <b>2.3 microseconds</b> on the same STM32. The numbers are not * The Context Switch just takes <b>2.3 microseconds</b> on the same STM32.
* pulled out of thin air, it is the output of the included test suite. * The numbers are not pulled out of thin air, it is the output of the
* included test suite.
* *
* <h3>Tests and metrics</h3> * <h3>Tests and metrics</h3>
* I think it is nice to know how an OS is tested and how it performs before * I think it is nice to know how an OS is tested and how it performs before