From 8486b10c8ff5989c37f92ad028dc7e3ffb9846a1 Mon Sep 17 00:00:00 2001 From: gdisirio Date: Wed, 11 Feb 2009 21:05:12 +0000 Subject: git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@753 35acf78f-673a-0410-8e92-d51de3d6d3f4 --- docs/ch.txt | 25 ++++++++----------------- docs/src/goals.dox | 43 +++++++++++++++++++++++-------------------- 2 files changed, 31 insertions(+), 37 deletions(-) diff --git a/docs/ch.txt b/docs/ch.txt index 2bf0721ec..b62fa38ca 100644 --- a/docs/ch.txt +++ b/docs/ch.txt @@ -29,31 +29,24 @@ * Source Wikipedia. * *

Features

- * - Free software, GPL3 licensed. + * - Free software, GPL3 licensed. Stable releases include a exception clause + * to the GPL. * - Designed for realtime applications. * - 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.
- * 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. - * - 128 priority levels. - * - Multiple threads at the same priority level allowed. + * - 128 priority levels. Multiple threads at the same priority level allowed. * - Round robin scheduling for threads at the same priority level. * - Offers threads, virtual timers, semaphores, mutexes, condvars, * event flags, messages, I/O queues. * - No static setup at compile time, there is no need to configure a maximum * number of all the above objects. + * - PC simulator target included, the development can be done on the PC + * using MinGW.
+ * 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 * and declaratively allocated. - * - Threads, Semaphores, Event Sources, Virtual Timers creation/deletion at - * runtime. * - Optional, thread safe, Heap Allocator subsystem. * - Optional, thread safe, Memory Pools Allocator subsystem. * - 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 * speed optimizations on. The size can shrink under 2KiB by disabling the * 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. * . *

Related pages

diff --git a/docs/src/goals.dox b/docs/src/goals.dox index 4df7eaba7..f0de70da7 100644 --- a/docs/src/goals.dox +++ b/docs/src/goals.dox @@ -23,7 +23,7 @@ *

Another RTOS?

* The first question to be answered is: there was really the need for YET * ANOTHER RTOS?
- * 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 * had far less features than the current product it was complete and * functioning. ChibiOS/RT is just a new (and silly) name given to @@ -37,45 +37,48 @@ * - I wanted another toy. * . *

Why is it different?

- * In itself it implements ideas already seen in other projects but never - * all together in a single FOSS project. There are some basic choices in - * ChibiOS/RT (mostly derived by its ancestor): + * Well, there are some design choices that should be explained and contribute + * to make ChibiOS/RT a peculiar design. Nothing really new by 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 fixed size tables or structures

- * No tables to configure, no arrays that can be filled and overflow at - * runtime. Everything without practical upper bounds (except for resource - * limits and numerical upper bounds of course). + *

No tables or other fixed structures

+ * The kernel has no internal tables, there is nothing that must be configured + * at design 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. Things that are not there cannot go wrong and take no space. * *

No error conditions and no error checks

- * 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 * 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 - * exists but only when the debug switch is activated.
+ * as examples. The APIs are not slowed down by parameter checks, + * parameter checks (and consistency checks) do exists but only when the + * debug switch is activated.
* All the static core APIs always succeed if correct parameters are passed. * *

Very simple APIs

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

Damn fast and compact

+ *

Fast and compact

* 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 - * with all the subsystems activated is well below 8KiB (32bit ARM code, the - * least space efficient) and can shrink down below 2KiB. It would be + * size with all the subsystems activated is well below 8KiB (32bit ARM code, + * the least space efficient) and can shrink down below 2KiB. It would be * 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. * . - * About the "fast" part, it is able to start/wait/exit more than 200,000 - * threads per second on a 72MHz STM32 (Cortex-M3). The Context Switch just - * takes 2.3 microseconds on the same STM32. The numbers are not - * pulled out of thin air, it is the output of the included test suite. + * About the "fast" part, the kernel is able to start/exit more than + * 200,000 threads per second on a 72MHz STM32 (Cortex-M3). + * The Context Switch just takes 2.3 microseconds on the same STM32. + * The numbers are not pulled out of thin air, it is the output of the + * included test suite. * *

Tests and metrics

* I think it is nice to know how an OS is tested and how it performs before -- cgit v1.2.3