Fix the double quotes.

c_user/barrier_manager.rst

@@ -106,9 +106,9 @@ Obtaining Barrier IDs
 
 When a barrier is created, RTEMS generates a unique barrier ID and assigns it
 to the created barrier until it is deleted.  The barrier ID may be obtained by
-either of two methods.  First, as the result of an invocation of
-the``rtems_barrier_create`` directive, the barrier ID is stored in a user
-provided location.  Second, the barrier ID may be obtained later using the
+either of two methods.  First, as the result of an invocation of the
+``rtems_barrier_create`` directive, the barrier ID is stored in a user provided
+location.  Second, the barrier ID may be obtained later using the
 ``rtems_barrier_ident`` directive.  The barrier ID is used by other barrier
 manager directives to access this barrier.
 

c_user/clock_manager.rst

@@ -146,8 +146,8 @@ RTEMS provides the ``rtems_clock_tick`` directive which is called from the
 user's real-time clock ISR to inform RTEMS that a tick has elapsed.  The tick
 frequency value, defined in microseconds, is a configuration parameter found in
 the Configuration Table.  RTEMS divides one million microseconds (one second)
-by the number of microseconds per tick to determine the number of calls to
-the``rtems_clock_tick`` directive per second.  The frequency of
+by the number of microseconds per tick to determine the number of calls to the
+``rtems_clock_tick`` directive per second.  The frequency of
 ``rtems_clock_tick`` calls determines the resolution (granularity) for all time
 dependent RTEMS actions.  For example, calling ``rtems_clock_tick`` ten times
 per second yields a higher resolution than calling ``rtems_clock_tick`` two

c_user/configuring_a_system.rst

@@ -88,8 +88,8 @@ The memory area for the RTEMS Workspace is determined by the BSP.  In case the
 RTEMS Workspace is too large for the available memory, then a fatal run-time
 error occurs and the system terminates.
 
-The file ``<rtems/confdefs.h>`` will calculate the value of
-the``work_space_size`` parameter of the Configuration Table. There are many
+The file ``<rtems/confdefs.h>`` will calculate the value of the
+``work_space_size`` parameter of the Configuration Table. There are many
 parameters the application developer can specify to help ``<rtems/confdefs.h>``
 in its calculations.  Correctly specifying the application requirements via
 parameters such as ``CONFIGURE_EXTRA_TASK_STACKS`` and

c_user/interrupt_manager.rst

@@ -408,8 +408,8 @@ returns to the caller.
 This directive will not cause the calling task to be preempted.
 
 This directive is only available on uni-processor configurations.  The
-directives ``rtems_interrupt_local_disable``
-and``rtems_interrupt_local_enable`` is available on all configurations.
+directives ``rtems_interrupt_local_disable`` and
+``rtems_interrupt_local_enable`` is available on all configurations.
 
 .. _rtems_interrupt_local_disable:
 

c_user/key_concepts.rst

@@ -48,7 +48,7 @@ Although not required by RTEMS, object names are often composed of four ASCII
 characters which help identify that object.  For example, a task which causes a
 light to blink might be called "LITE".  The ``rtems_build_name`` routine is
 provided to build an object name from four ASCII characters.  The following
-example illustrates this: .. code:: c
+example illustrates this:
 
 .. code:: c
 
@@ -59,7 +59,9 @@ However, it is not required that the application use ASCII characters to build
 object names.  For example, if an application requires one-hundred tasks, it
 would be difficult to assign meaningful ASCII names to each task.  A more
 convenient approach would be to name them the binary values one through
-one-hundred, respectively... index:: rtems_object_get_name
+one-hundred, respectively.
+
+.. index:: rtems_object_get_name
 
 RTEMS provides a helper routine, ``rtems_object_get_name``, which can be used
 to obtain the name of any RTEMS object using just its ID.  This routine

c_user/multiprocessing.rst

@@ -159,9 +159,9 @@ application:
    and returns it to the originating node.
 
 #. The MPCI layer on the originating node senses the arrival of a packet
-   (typically via an interrupt), and calls the
-   RTEMS``rtems_multiprocessing_announce`` directive.  This directive readies
-   the Multiprocessing Server.
+   (typically via an interrupt), and calls the RTEMS
+   ``rtems_multiprocessing_announce`` directive.  This directive readies the
+   Multiprocessing Server.
 
 #. The Multiprocessing Server calls the user-provided MPCI routine
    ``RECEIVE_PACKET``, readies the original requesting task, and blocks until

c_user/semaphore_manager.rst

@@ -299,8 +299,8 @@ When a semaphore is created, RTEMS generates a unique semaphore ID and assigns
 it to the created semaphore until it is deleted.  The semaphore ID may be
 obtained by either of two methods.  First, as the result of an invocation of
 the ``rtems_semaphore_create`` directive, the semaphore ID is stored in a user
-provided location.  Second, the semaphore ID may be obtained later using
-the``rtems_semaphore_ident`` directive.  The semaphore ID is used by other
+provided location.  Second, the semaphore ID may be obtained later using the
+``rtems_semaphore_ident`` directive.  The semaphore ID is used by other
 semaphore manager directives to access this semaphore.
 
 Acquiring a Semaphore

c_user/task_manager.rst

@@ -281,8 +281,9 @@ If the supported processor type does not have hardware floating capabilities or
 a standard numeric coprocessor, RTEMS will not provide built-in support for
 hardware floating point on that processor.  In this case, all tasks are
 considered ``RTEMS_NO_FLOATING_POINT`` whether created as
-``RTEMS_FLOATING_POINT`` or``RTEMS_NO_FLOATING_POINT`` tasks.  A floating point
-emulation software library must be utilized for floating point operations.
+``RTEMS_FLOATING_POINT`` or ``RTEMS_NO_FLOATING_POINT`` tasks.  A floating
+point emulation software library must be utilized for floating point
+operations.
 
 On some processors, it is possible to disable the floating point unit
 dynamically.  If this capability is supported by the target processor, then
@@ -534,8 +535,8 @@ task's name and ID become inactive at this time, and any subsequent references
 to either of them is invalid.  In fact, RTEMS may reuse the task ID for another
 task which is created later in the application.
 
-Unexpired delay timers (i.e. those used by``rtems_task_wake_after``
-and``rtems_task_wake_when``) and timeout timers associated with the task are
+Unexpired delay timers (i.e. those used by ``rtems_task_wake_after`` and
+``rtems_task_wake_when``) and timeout timers associated with the task are
 automatically deleted, however, other resources dynamically allocated by the
 task are NOT automatically returned to RTEMS.  Therefore, before a task is
 deleted, all of its dynamically allocated resources should be deallocated by