From bae98eb8d8e752aa084a2438aa99d5f72e3f1247 Mon Sep 17 00:00:00 2001
From: gdisirio <gdisirio@35acf78f-673a-0410-8e92-d51de3d6d3f4>
Date: Thu, 22 Jan 2009 15:37:29 +0000
Subject: git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@666
 35acf78f-673a-0410-8e92-d51de3d6d3f4

---
 docs/src/jitter.dox | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

(limited to 'docs/src')

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