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

1 files changed, 8 insertions, 7 deletions

diff --git a/docs/src/jitter.dox b/docs/src/jitter.dox
index 733e30ef6..4bbedd7b7 100644
--- a/docs/src/jitter.dox
+++ b/docs/src/jitter.dox
@@ -3,21 +3,21 @@
  * @{

  * Response time jitter is one of the most sneaky source of problems when

  * designing a real time system. When using a RTOS like ChibiOS/RT one must

- * be aware of what Jitter is and how it can affect the performance of the

+ * be aware of what the jitter is and how it can affect the performance of the

  * system.<br>

  * A good place to start is this

  * <a href="http://en.wikipedia.org/wiki/Jitter">Wikipedia article</a>.

  *

  * <h2>Jitter Sources</h2>

- * Under ChibiOS/RT (or any other similar RTOS) there are several jitter

- * possible sources:

+ * Under ChibiOS/RT (or any other similar RTOS) there are several possible

+ * jitter sources:

  * -# Hardware interrupts latency.

  * -# Interrupts service time and priority.

  * -# Kernel lock zones.

  * -# Higher priority threads activity.

  *

  * <h2>Jitter mitigation countermeasures</h2>

- * For each of the previously described jitter source there are possible

+ * For each of the previously described jitter sources there are possible

  * mitigation actions.

  *

  * <h3>Hardware interrupts latency</h3>

@@ -49,13 +49,14 @@
  * As example, in the ARM port, FIQ sources are not affected by the

  * kernel-generated jitter. The Cortex-M3 port is even better thanks to its

  * hardware-assisted interrupt architecture allowing handlers preemption,

- * late switch, tail chaining etc. See the notes about the various @ref Ports.

+ * late arriving, tail chaining etc. See the notes about the various

+ * @ref Ports.

  *

  * <h3>Kernel lock zones</h3>

  * The OS kernel protects some critical internal data structure by disabling

  * (fully in simple architecture, to some extent in more advanced

  * microcontrollers) the interrupt sources. Because of this the kernel itself

- * is a jitter source, a good OS design minimizes the jitter generated by the

+ * is a jitter cause, a good OS design minimizes the jitter generated by the

  * kernel by both using adequate data structure, algorithms and good coding

  * practices.<br>

  * A good OS design is not the whole story, some OS primitives may generate

@@ -72,6 +73,6 @@
  * by carefully assigning priorities to the various threads and carefully

  * designing mutual exclusion zones.<br>

  * The use of the proper synchronization mechanism (semaphores, mutexes, events,

- * messages and so on) also helps to improve the system performance.

+ * messages and so on) also helps to improve the overall system performance.

  */

 /** @} */