rusefi
/
ChibiOS
mirror of https://github.com/rusefi/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@755 35acf78f-673a-0410-8e92-d51de3d6d3f4

This commit is contained in:
gdisirio 2009-02-12 21:29:43 +00:00
parent ea63ddb719
commit af4eb6b790
2 changed files with 19 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
docs/src/goals.dox
View File

@ -38,7 +38,7 @@
* . * .
* <h2>Why is it different?</h2> * <h2>Why is it different?</h2>
* Well, there are some design choices that should be explained and contribute * 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: * the whole is interesting:
* *
* <h3>Static design</h3> * <h3>Static design</h3>
@ -46,11 +46,11 @@
* 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 tables or other fixed structures</h3> * <h3>No tables, arrays or other fixed structures</h3>
* The kernel has no internal tables, there is nothing that must be configured * 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 * 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 * 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.
* *
* <h3>No error conditions and no error checks</h3> * <h3>No error conditions and no error checks</h3>
* All the system APIs have no error conditions, all the previous points are * 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 * parameter checks (and consistency checks) do exists but only when the
* debug switch is activated.<br> * 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.
* Exception to this are the optional allocators APIs that, of course,
* can report memory exhausted.
* *
* <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 does a single thing with no options. * more no less. Each API does a single thing with no options.
* *
* <h3>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 and then on code size. This does not mean that the OS is large,
* size with all the subsystems activated is well below 8KiB (32bit ARM code, * the kernel size with all the subsystems activated is around <b>5.3KiB</b>
* the least space efficient) and can shrink down below 2KiB. It would be * and can shrink down around to <b>1.2Kib</b> in a minimal configuration
* possible to make something smaller but: * (STM32, Cortex-M3). It would be possible to make something even smaller but:
* -# It would be pointless, it is already @a really 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 trade efficiency or features in order to save few bytes.
* . * .
* About the "fast" part, the kernel is able to start/exit more than * About the "fast" part, the kernel is able to start/exit more than
* <b>200,000 threads per second</b> on a 72MHz STM32 (Cortex-M3). * <b>200,000 threads per second</b> on a 72MHz STM32.
* The Context Switch just takes <b>2.3 microseconds</b> on the same STM32. * The Context Switch takes <b>2.3 microseconds</b> on the same STM32.
* 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
@ -88,4 +88,3 @@
* the test suite and the OS benchmarks. * the test suite and the OS benchmarks.
*/ */
/** @} */ /** @} */

13
docs/src/mutualexcl.dox
View File

@ -93,11 +93,10 @@
* - Semaphore queues are FIFO ordered by default, an option exist to make * - Semaphore queues are FIFO ordered by default, an option exist to make
* them priority ordered but this can impact I/O performance because * them priority ordered but this can impact I/O performance because
* semaphores are used in I/O queues. * semaphores are used in I/O queues.
* - Semaphores do not implement the priority inheritance algorithm so the * - Semaphores do not implement the Priority Inheritance algorithm.
* priority inversion problem is not mitigated.
* . * .
* <h3>When use Semaphores</h3> * <h3>When use Semaphores</h3>
* - 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. * algorithm.
* - When RAM/ROM space is scarce. * - When RAM/ROM space is scarce.
* . * .
@ -116,7 +115,7 @@
* <h2>Mutual exclusion by Mutexes</h2> * <h2>Mutual exclusion by Mutexes</h2>
* The mutexes, also known as binary semaphores (we choose to not use this * The mutexes, also known as binary semaphores (we choose to not use this
* terminology to avoid confusion with counting semaphores), are the mechanism * 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.
* *
* <h3>Advantages</h3> * <h3>Advantages</h3>
* - Mutexes implement the Priority Inheritance algorithm that is an important * - 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. * - Almost free as code size, you need no semaphores nor mutexes.
* - No RAM overhead. * - No RAM overhead.
* - Fast execution, priority change is a quick operation under ChibiOS/RT. * - Fast execution, priority change is a quick operation under ChibiOS/RT.
* - The priority ceiling protocol that can help mitigate the Priority * - The Priority Ceiling protocol can help mitigate potential Priority
* Inversion problem. * Inversion problems.
* . * .
* <h3>Disadvantages</h3> * <h3>Disadvantages</h3>
* - Makes the design more complicated because priorities must be assigned to * - Makes the design more complicated because priorities must be assigned to
@ -207,7 +206,7 @@
* and server. * and server.
* - Two context switches are required for each request to the server (but * - Two context switches are required for each request to the server (but
* ChibiOSRT is very efficient at that). * ChibiOSRT is very efficient at that).
* - Requires a dedicated thread. * - Requires a dedicated thread as server.
* . * .
*/ */
/** @} */ /** @} */