diff options
| -rw-r--r-- | docs/src/goals.dox | 27 | ||||
| -rw-r--r-- | 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 @@ * .
* <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 by itself but
+ * to make ChibiOS/RT a peculiar design. Nothing really new in itself but
* the whole is interesting:
*
* <h3>Static design</h3>
@@ -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.
*
- * <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
* 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.
*
* <h3>No error conditions and no error checks</h3>
* 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.<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>
* 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.
*
* <h3>Fast and compact</h3>
- * 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 <b>5.3KiB</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 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
- * <b>200,000 threads per second</b> on a 72MHz STM32 (Cortex-M3).
- * The Context Switch just 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.
+ * <b>200,000 threads per second</b> on a 72MHz STM32.
+ * The Context Switch takes <b>2.3 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
@@ -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.
* .
* <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.
* - When RAM/ROM space is scarce.
* .
@@ -116,7 +115,7 @@ * <h2>Mutual exclusion by Mutexes</h2>
* 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.
*
* <h3>Advantages</h3>
* - 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.
* .
* <h3>Disadvantages</h3>
* - 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.
* .
*/
/** @} */
|