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

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.
  */
 /** @} */
- 

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.
  * .
  */
 /** @} */