From af4eb6b7901f0871d46b4de27486f47266f24e99 Mon Sep 17 00:00:00 2001 From: gdisirio Date: Thu, 12 Feb 2009 21:29:43 +0000 Subject: [PATCH] git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@755 35acf78f-673a-0410-8e92-d51de3d6d3f4 --- docs/src/goals.dox | 27 +++++++++++++-------------- docs/src/mutualexcl.dox | 13 ++++++------- 2 files changed, 19 insertions(+), 21 deletions(-) diff --git a/docs/src/goals.dox b/docs/src/goals.dox index d19c7d70a..3a2209f0c 100644 --- a/docs/src/goals.dox +++ b/docs/src/goals.dox @@ -38,7 +38,7 @@ * . *

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 by itself but + * to make ChibiOS/RT a peculiar design. Nothing really new in itself but * the whole is interesting: * *

Static design

@@ -46,11 +46,11 @@ * 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 or other fixed structures

+ *

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. Things that are not there cannot go wrong and take no space. + * allocated. * *

No error conditions and no error checks

* All the system APIs have no error conditions, all the previous points are @@ -60,25 +60,25 @@ * 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. + * Exception to this are the optional allocators APIs that, of course, + * can report memory exhausted. * *

Very simple APIs

* Every API should have the parameters you would expect for that function, no * more no less. Each API does a single thing with no options. * *

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 - * 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: + * 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 sacrifice efficiency or features in order to save few bytes. + * -# 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 (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. + * 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 @@ -88,4 +88,3 @@ * the test suite and the OS benchmarks. */ /** @} */ - \ No newline at end of file diff --git a/docs/src/mutualexcl.dox b/docs/src/mutualexcl.dox index 367618d5d..ae6f57c0a 100644 --- a/docs/src/mutualexcl.dox +++ b/docs/src/mutualexcl.dox @@ -93,11 +93,10 @@ * - Semaphore queues are FIFO ordered by default, an option exist to make * them priority ordered but this can impact I/O performance because * semaphores are used in I/O queues. - * - Semaphores do not implement the priority inheritance algorithm so the - * priority inversion problem is not mitigated. + * - Semaphores do not implement the Priority Inheritance algorithm. * . *

When use Semaphores

- * - When you don't need queuing by priority nor the priority inheritance + * - When you don't need queuing by priority nor the Priority Inheritance * algorithm. * - When RAM/ROM space is scarce. * . @@ -116,7 +115,7 @@ *

Mutual exclusion by Mutexes

* The mutexes, also known as binary semaphores (we choose to not use this * terminology to avoid confusion with counting semaphores), are the mechanism - * intended as general solution for the mutual exclusion problem. + * intended as general solution for Mutual Exclusion. * *

Advantages

* - Mutexes implement the Priority Inheritance algorithm that is an important @@ -154,8 +153,8 @@ * - Almost free as code size, you need no semaphores nor mutexes. * - No RAM overhead. * - Fast execution, priority change is a quick operation under ChibiOS/RT. - * - The priority ceiling protocol that can help mitigate the Priority - * Inversion problem. + * - The Priority Ceiling protocol can help mitigate potential Priority + * Inversion problems. * . *

Disadvantages

* - Makes the design more complicated because priorities must be assigned to @@ -207,7 +206,7 @@ * and server. * - Two context switches are required for each request to the server (but * ChibiOSRT is very efficient at that). - * - Requires a dedicated thread. + * - Requires a dedicated thread as server. * . */ /** @} */