Fix the double quotes.

c_user/barrier_manager.rst

@@ -51,7 +51,7 @@ Automatic barriers are created with a limit to the number of tasks which may
 simultaneously block at the barrier.  Once this limit is reached, all of the
 tasks are released.  For example, if the automatic limit is ten tasks, then the
 first nine tasks calling the ``rtems_barrier_wait`` directive will block.  When
-the tenth task calls the``rtems_barrier_wait`` directive, the nine blocked
+the tenth task calls the ``rtems_barrier_wait`` directive, the nine blocked
 tasks will be released and the tenth task returns to the caller without
 blocking.
 
@@ -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
+either of two methods.  First, as the result of an invocation of the
-the``rtems_barrier_create`` directive, the barrier ID is stored in a user
+``rtems_barrier_create`` directive, the barrier ID is stored in a user provided
-provided location.  Second, the barrier ID may be obtained later using the
+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
+by the number of microseconds per tick to determine the number of calls to the
-the``rtems_clock_tick`` directive per second.  The frequency of
+``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
@@ -171,7 +171,7 @@ can be returned in either native or *UNIX-style* format.  Additionally, the
 application can obtain date and time related information such as the number of
 seconds since the RTEMS epoch, the number of ticks since the executive was
 initialized, and the number of ticks per second.  The information returned by
-the``rtems_clock_get`` directive is dependent on the option selected by the
+the ``rtems_clock_get`` directive is dependent on the option selected by the
 caller.  This is specified using one of the following constants associated with
 the enumerated type ``rtems_clock_get_options``:
 
@@ -295,7 +295,7 @@ code is returned.  The caller can always obtain the number of ticks per second
 the executive was initialized option is ``RTEMS_CLOCK_GET_TICKS_SINCE_BOOT``).
 
 The ``option`` argument may taken on any value of the enumerated type
-``rtems_clock_get_options``.  The data type expected for``time_buffer`` is
+``rtems_clock_get_options``.  The data type expected for ``time_buffer`` is
 based on the value of ``option`` as indicated below:
 
 .. index:: rtems_clock_get_options

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 file ``<rtems/confdefs.h>`` will calculate the value of the
-the``work_space_size`` parameter of the Configuration Table. There are many
+``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
@@ -1915,7 +1915,7 @@ run-time stack bounds checking.
 
 **NOTES:**
 
-In 4.9 and older, this configuration parameter was named``STACK_CHECKER_ON``.
+In 4.9 and older, this configuration parameter was named ``STACK_CHECKER_ON``.
 
 This increases the time required to create tasks as well as adding overhead to
 each context switch.
@@ -3321,7 +3321,7 @@ The order of precedence for configuring the IDLE task stack size is:
 
 - If defined, then the BSP specific ``BSP_IDLE_TASK_SIZE``.
 
-- If defined, then the application specified``CONFIGURE_IDLE_TASK_SIZE``.
+- If defined, then the application specified ``CONFIGURE_IDLE_TASK_SIZE``.
 
 .. COMMENT: XXX - add cross references to other related values.
 

c_user/dual_ports_memory_manager.rst

@@ -65,7 +65,7 @@ When a port is created, RTEMS generates a unique port ID and assigns it to the
 created port until it is deleted.  The port ID may be obtained by either of two
 methods.  First, as the result of an invocation of the``rtems_port_create``
 directive, the task ID is stored in a user provided location.  Second, the port
-ID may be obtained later using the``rtems_port_ident`` directive.  The port ID
+ID may be obtained later using the ``rtems_port_ident`` directive.  The port ID
 is used by other dual-ported memory manager directives to access this port.
 
 Converting an Address

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``
+directives ``rtems_interrupt_local_disable`` and
-and``rtems_interrupt_local_enable`` is available on all configurations.
+``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
+   (typically via an interrupt), and calls the RTEMS
-   RTEMS``rtems_multiprocessing_announce`` directive.  This directive readies
+   ``rtems_multiprocessing_announce`` directive.  This directive readies the
-   the Multiprocessing Server.
+   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

@@ -231,7 +231,7 @@ This example demonstrates the attribute_set parameter needed to create a local
 semaphore with the task priority waiting queue discipline.  The attribute_set
 parameter passed to the ``rtems_semaphore_create`` directive could be either
 ``RTEMS_PRIORITY`` or ``RTEMS_LOCAL | RTEMS_PRIORITY``.  The attribute_set
-parameter can be set to``RTEMS_PRIORITY`` because ``RTEMS_LOCAL`` is the
+parameter can be set to ``RTEMS_PRIORITY`` because ``RTEMS_LOCAL`` is the
 default for all created tasks.  If a similar semaphore were to be known
 globally, then the attribute_set parameter would be ``RTEMS_GLOBAL |
 RTEMS_PRIORITY``.
@@ -298,9 +298,9 @@ Obtaining Semaphore IDs
 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
+the ``rtems_semaphore_create`` directive, the semaphore ID is stored in a user
-provided location.  Second, the semaphore ID may be obtained later using
+provided location.  Second, the semaphore ID may be obtained later using the
-the``rtems_semaphore_ident`` directive.  The semaphore ID is used by other
+``rtems_semaphore_ident`` directive.  The semaphore ID is used by other
 semaphore manager directives to access this semaphore.
 
 Acquiring a Semaphore
@@ -341,7 +341,7 @@ Releasing a Semaphore
 ---------------------
 
 The ``rtems_semaphore_release`` directive is used to release the specified
-semaphore.  A simplified version of the``rtems_semaphore_release`` directive
+semaphore.  A simplified version of the ``rtems_semaphore_release`` directive
 can be described as follows:
 
     If there sre no tasks are waiting on this semaphore then increment the

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
+``RTEMS_FLOATING_POINT`` or ``RTEMS_NO_FLOATING_POINT`` tasks.  A floating
-emulation software library must be utilized for floating point operations.
+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
@@ -367,8 +368,8 @@ practice to specify default components.  If all defaults are desired, then
 
 This example demonstrates the attribute_set parameter needed to create a local
 task which utilizes the numeric coprocessor.  The attribute_set parameter could
-be ``RTEMS_FLOATING_POINT`` or``RTEMS_LOCAL | RTEMS_FLOATING_POINT``.  The
+be ``RTEMS_FLOATING_POINT`` or ``RTEMS_LOCAL | RTEMS_FLOATING_POINT``.  The
-attribute_set parameter can be set to``RTEMS_FLOATING_POINT`` because
+attribute_set parameter can be set to ``RTEMS_FLOATING_POINT`` because
 ``RTEMS_LOCAL`` is the default for all created tasks.  If the task were global
 and used the numeric coprocessor, then the attribute_set parameter would be
 ``RTEMS_GLOBAL | RTEMS_FLOATING_POINT``.
@@ -385,21 +386,21 @@ corresponding mask constant is listed below:
  :class: rtems-table
 
  * - ``RTEMS_PREEMPT``
-   - is masked by``RTEMS_PREEMPT_MASK`` and enables preemption
+   - is masked by ``RTEMS_PREEMPT_MASK`` and enables preemption
  * - ``RTEMS_NO_PREEMPT``
-   - is masked by``RTEMS_PREEMPT_MASK`` and disables preemption
+   - is masked by ``RTEMS_PREEMPT_MASK`` and disables preemption
  * - ``RTEMS_NO_TIMESLICE``
-   - is masked by``RTEMS_TIMESLICE_MASK`` and disables timeslicing
+   - is masked by ``RTEMS_TIMESLICE_MASK`` and disables timeslicing
  * - ``RTEMS_TIMESLICE``
-   - is masked by``RTEMS_TIMESLICE_MASK`` and enables timeslicing
+   - is masked by ``RTEMS_TIMESLICE_MASK`` and enables timeslicing
  * - ``RTEMS_ASR``
-   - is masked by``RTEMS_ASR_MASK`` and enables ASR processing
+   - is masked by ``RTEMS_ASR_MASK`` and enables ASR processing
  * - ``RTEMS_NO_ASR``
-   - is masked by``RTEMS_ASR_MASK`` and disables ASR processing
+   - is masked by ``RTEMS_ASR_MASK`` and disables ASR processing
  * - ``RTEMS_INTERRUPT_LEVEL(0)``
-   - is masked by``RTEMS_INTERRUPT_MASK`` and enables all interrupts
+   - is masked by ``RTEMS_INTERRUPT_MASK`` and enables all interrupts
  * - ``RTEMS_INTERRUPT_LEVEL(n)``
-   - is masked by``RTEMS_INTERRUPT_MASK`` and sets interrupts level n
+   - is masked by ``RTEMS_INTERRUPT_MASK`` and sets interrupts level n
 
 Mode values are specifically designed to be mutually exclusive, therefore
 bitwise OR and addition operations are equivalent as long as each mode appears
@@ -411,7 +412,7 @@ should be used.
 
 The following example demonstrates the mode and mask parameters used with the
 ``rtems_task_mode`` directive to place a task at interrupt level 3 and make it
-non-preemptible.  The mode should be set to``RTEMS_INTERRUPT_LEVEL(3) |
+non-preemptible.  The mode should be set to ``RTEMS_INTERRUPT_LEVEL(3) |
 RTEMS_NO_PREEMPT`` to indicate the desired preemption mode and interrupt level,
 while the mask parameter should be set to ``RTEMS_INTERRUPT_MASK |
 RTEMS_NO_PREEMPT_MASK`` to indicate that the calling task's interrupt level and
@@ -505,7 +506,7 @@ Changing Task Priority
 
 The ``rtems_task_set_priority`` directive is used to obtain or change the
 current priority of either the calling task or another task.  If the new
-priority requested is``RTEMS_CURRENT_PRIORITY`` or the task's actual priority,
+priority requested is ``RTEMS_CURRENT_PRIORITY`` or the task's actual priority,
 then the current priority will be returned and the task's priority will remain
 unchanged.  If the task's priority is altered, then the task will be scheduled
 according to its new priority.
@@ -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``
+Unexpired delay timers (i.e. those used by ``rtems_task_wake_after`` and
-and``rtems_task_wake_when``) and timeout timers associated with the task are
+``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