From f02e87257aa62bd8b78fb199a33a3cf1a5ad18be Mon Sep 17 00:00:00 2001 From: Chris Johns Date: Thu, 18 Feb 2016 10:32:05 +1100 Subject: Fix the double quotes. --- c_user/barrier_manager.rst | 8 ++++---- c_user/clock_manager.rst | 8 ++++---- c_user/configuring_a_system.rst | 8 ++++---- c_user/dual_ports_memory_manager.rst | 2 +- c_user/interrupt_manager.rst | 4 ++-- c_user/key_concepts.rst | 6 ++++-- c_user/multiprocessing.rst | 6 +++--- c_user/semaphore_manager.rst | 10 +++++----- c_user/task_manager.rst | 33 +++++++++++++++++---------------- 9 files changed, 44 insertions(+), 41 deletions(-) diff --git a/c_user/barrier_manager.rst b/c_user/barrier_manager.rst index 0ef8677..616d922 100644 --- a/c_user/barrier_manager.rst +++ b/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 -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. diff --git a/c_user/clock_manager.rst b/c_user/clock_manager.rst index 40d984f..5b42bb6 100644 --- a/c_user/clock_manager.rst +++ b/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 @@ -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 diff --git a/c_user/configuring_a_system.rst b/c_user/configuring_a_system.rst index b55eea1..e427501 100644 --- a/c_user/configuring_a_system.rst +++ b/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 ```` will calculate the value of -the``work_space_size`` parameter of the Configuration Table. There are many +The file ```` 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 ```` 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. diff --git a/c_user/dual_ports_memory_manager.rst b/c_user/dual_ports_memory_manager.rst index 6088ece..b81aa1e 100644 --- a/c_user/dual_ports_memory_manager.rst +++ b/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 diff --git a/c_user/interrupt_manager.rst b/c_user/interrupt_manager.rst index acb8014..b1b95a1 100644 --- a/c_user/interrupt_manager.rst +++ b/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: diff --git a/c_user/key_concepts.rst b/c_user/key_concepts.rst index 9927584..e9a3689 100644 --- a/c_user/key_concepts.rst +++ b/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 diff --git a/c_user/multiprocessing.rst b/c_user/multiprocessing.rst index 6bb3f12..e709bf3 100644 --- a/c_user/multiprocessing.rst +++ b/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 diff --git a/c_user/semaphore_manager.rst b/c_user/semaphore_manager.rst index 620dcbf..668c951 100644 --- a/c_user/semaphore_manager.rst +++ b/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 -provided location. Second, the semaphore ID may be obtained later using -the``rtems_semaphore_ident`` directive. The semaphore ID is used by other +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 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 diff --git a/c_user/task_manager.rst b/c_user/task_manager.rst index 56cdaf6..2a4c8a5 100644 --- a/c_user/task_manager.rst +++ b/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 @@ -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 -attribute_set parameter can be set to``RTEMS_FLOATING_POINT`` because +be ``RTEMS_FLOATING_POINT`` or ``RTEMS_LOCAL | RTEMS_FLOATING_POINT``. The +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`` -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 -- cgit v1.2.3