Convert all Unicode to ASCII(128)

35 files changed, 308 insertions, 308 deletions

diff --git a/c_user/barrier_manager.rst b/c_user/barrier_manager.rst
index f2dfcf8..188b563 100644
--- a/c_user/barrier_manager.rst
+++ b/c_user/barrier_manager.rst
@@ -126,7 +126,7 @@ unblock all tasks waiting at the barrier and the caller will
 return immediately.
 
 When the task does wait to acquire the barrier, then it
-is placed in the barrier’s task wait queue in FIFO order.
+is placed in the barrier's task wait queue in FIFO order.
 All tasks waiting on a barrier are returned an error
 code when the barrier is deleted.
 
@@ -143,17 +143,17 @@ Deleting a Barrier
 
 The ``rtems_barrier_delete`` directive removes a barrier
 from the system and frees its control block.  A barrier can be
-deleted by any local task that knows the barrier’s ID.  As a
+deleted by any local task that knows the barrier's ID.  As a
 result of this directive, all tasks blocked waiting for the
 barrier to be released, will be readied and returned a status code which
 indicates that the barrier was deleted.  Any subsequent
-references to the barrier’s name and ID are invalid.
+references to the barrier's name and ID are invalid.
 
 Directives
 ==========
 
-This section details the barrier manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the barrier manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.
 
@@ -179,7 +179,7 @@ BARRIER_CREATE - Create a barrier
 ``RTEMS_SUCCESSFUL`` - barrier created successfully
 ``RTEMS_INVALID_NAME`` - invalid barrier name
 ``RTEMS_INVALID_ADDRESS`` - ``id`` is NULL
-``RTEMS_TOO_MANY`` - too many barriers created 
+``RTEMS_TOO_MANY`` - too many barriers created
 
 **DESCRIPTION:**
 
@@ -268,7 +268,7 @@ BARRIER_DELETE - Delete a barrier
 **DIRECTIVE STATUS CODES:**
 
 ``RTEMS_SUCCESSFUL`` - barrier deleted successfully
-``RTEMS_INVALID_ID`` - invalid barrier id 
+``RTEMS_INVALID_ID`` -c invalid barrier id
 
 **DESCRIPTION:**
 
@@ -281,7 +281,7 @@ by RTEMS.
 **NOTES:**
 
 The calling task will be preempted if it is enabled
-by the task’s execution mode and a higher priority local task is
+by the task's execution mode and a higher priority local task is
 waiting on the deleted barrier.  The calling task will NOT be
 preempted if all of the tasks that are waiting on the barrier
 are remote tasks.
@@ -378,7 +378,7 @@ BARRIER_RELEASE - Release a barrier
 
 This directive releases the barrier specified by id.
 All tasks waiting at the barrier will be unblocked.
-If the running task’s preemption mode is enabled and one of
+If the running task's preemption mode is enabled and one of
 the unblocked tasks has a higher priority than the running task.
 
 **NOTES:**
diff --git a/c_user/board_support_packages.rst b/c_user/board_support_packages.rst
index 9e8449e..9b5b932 100644
--- a/c_user/board_support_packages.rst
+++ b/c_user/board_support_packages.rst
@@ -40,15 +40,15 @@ application.  Some of the hardware components may be initialized
 in this code as well as any application initialization that does
 not involve calls to RTEMS directives.
 
-The processor’s Interrupt Vector Table which will be used by the
+The processor's Interrupt Vector Table which will be used by the
 application may need to be set to the required value by the reset
 application initialization code.  Because interrupts are enabled
 automatically by RTEMS as part of the context switch to the first task,
 the Interrupt Vector Table MUST be set before this directive is invoked
-to ensure correct interrupt vectoring.  The processor’s Interrupt Vector
+to ensure correct interrupt vectoring.  The processor's Interrupt Vector
 Table must be accessible by RTEMS as it will be modified by the when
 installing user Interrupt Service Routines (ISRs) On some CPUs, RTEMS
-installs it’s own Interrupt Vector Table as part of initialization and
+installs it's own Interrupt Vector Table as part of initialization and
 thus these requirements are met automatically.  The reset code which is
 executed before the call to any RTEMS initialization routines has the
 following requirements:
@@ -66,7 +66,7 @@ following requirements:
 - Must initialize the stack pointer for the initialization process to
   that allocated.
 
-- Must initialize the processor’s Interrupt Vector Table.
+- Must initialize the processor's Interrupt Vector Table.
 
 - Must disable all maskable interrupts.
 
@@ -91,9 +91,9 @@ application.  If the processor supports interrupt nesting, the
 stack usage must include the deepest nest level.  The worst-case
 stack usage must account for the following requirements:
 
-- Processor’s interrupt stack frame
+- Processor's interrupt stack frame
 
-- Processor’s subroutine call stack frame
+- Processor's subroutine call stack frame
 
 - RTEMS system calls
 
@@ -115,7 +115,7 @@ interrupt service routines.
 
 The dedicated interrupt stack for the entire application on some
 architectures is supplied and initialized by the reset and initialization
-code of the user’s Board Support Package.  Whether allocated and
+code of the user's Board Support Package.  Whether allocated and
 initialized by the BSP or RTEMS, since all ISRs use this stack, the
 stack size must take into account the worst case stack usage by any
 combination of nested ISRs.
@@ -124,8 +124,8 @@ Processors Without a Separate Interrupt Stack
 ---------------------------------------------
 
 Some processors do not support a separate stack for interrupts.  In this
-case, without special assistance every task’s stack must include
-enough space to handle the task’s worst-case stack usage as well as
+case, without special assistance every task's stack must include
+enough space to handle the task's worst-case stack usage as well as
 the worst-case interrupt stack usage.  This is necessary because the
 worst-case interrupt nesting could occur while any task is executing.
 
diff --git a/c_user/chains.rst b/c_user/chains.rst
index 770fd5f..490d2b2 100644
--- a/c_user/chains.rst
+++ b/c_user/chains.rst
@@ -23,11 +23,11 @@ provided by RTEMS is:
 
 - ``rtems_chain_is_null_node`` - Is the node NULL ?
 
-- ``rtems_chain_head`` - Return the chain’s head
+- ``rtems_chain_head`` - Return the chain's head
 
-- ``rtems_chain_tail`` - Return the chain’s tail
+- ``rtems_chain_tail`` - Return the chain's tail
 
-- ``rtems_chain_are_nodes_equal`` - Are the node’s equal ?
+- ``rtems_chain_are_nodes_equal`` - Are the node's equal ?
 
 - ``rtems_chain_is_empty`` - Is the chain empty ?
 
@@ -106,8 +106,8 @@ foo structure from the list you perform the following:
     return (foo*) rtems_chain_get(control);
     }
 
-The node is placed at the start of the user’s structure to allow the
-node address on the chain to be easly cast to the user’s structure
+The node is placed at the start of the user's structure to allow the
+node address on the chain to be easly cast to the user's structure
 address.
 
 Controls
diff --git a/c_user/clock_manager.rst b/c_user/clock_manager.rst
index 900ddd0..5ea889f 100644
--- a/c_user/clock_manager.rst
+++ b/c_user/clock_manager.rst
@@ -103,15 +103,15 @@ also sometimes referred to as the automatic round-robin
 scheduling algorithm.  The length of time allocated to each task
 is known as the quantum or timeslice.
 
-The system’s timeslice is defined as an integral
+The system's timeslice is defined as an integral
 number of ticks, and is specified in the Configuration Table.
 The timeslice is defined for the entire system of tasks, but
 timeslicing is enabled and disabled on a per task basis.
 
 The ``rtems_clock_tick``
 directive implements timeslicing by
-decrementing the running task’s time-remaining counter when both
-timeslicing and preemption are enabled.  If the task’s timeslice
+decrementing the running task's time-remaining counter when both
+timeslicing and preemption are enabled.  If the task's timeslice
 has expired, then that task will be preempted if there exists a
 ready task of equal priority.
 
@@ -143,7 +143,7 @@ Announcing a Tick
 -----------------
 
 RTEMS provides the ``rtems_clock_tick`` directive which is
-called from the user’s real-time clock ISR to inform RTEMS that
+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
@@ -203,8 +203,8 @@ invoked before the date and time have been set.
 Directives
 ==========
 
-This section details the clock manager’s directives.
-A subsection is dedicated to each of this manager’s directives
+This section details the clock manager's directives.
+A subsection is dedicated to each of this manager's directives
 and describes the calling sequence, related constants, usage,
 and status codes.
 
diff --git a/c_user/configuring_a_system.rst b/c_user/configuring_a_system.rst
index b4d4066..f33df6b 100644
--- a/c_user/configuring_a_system.rst
+++ b/c_user/configuring_a_system.rst
@@ -103,7 +103,7 @@ porting software for which you do not know the object requirements.
 The space needed for stacks and for RTEMS objects will vary from
 one version of RTEMS and from one target processor to another.
 Therefore it is safest to use ``<rtems/confdefs.h>`` and specify
-your application’s requirements in terms of the numbers of objects and
+your application's requirements in terms of the numbers of objects and
 multiples of ``RTEMS_MINIMUM_STACK_SIZE``, as far as is possible. The
 automatic estimates of space required will in general change when:
 
@@ -158,7 +158,7 @@ Format to be followed for making changes in this file
 =====================================================
 
 - MACRO NAME
-  Should be alphanumeric. Can have ’_’ (underscore).
+  Should be alphanumeric. Can have '_' (underscore).
 
 - DATA TYPE
   Please refer to all existing formats.
@@ -167,29 +167,29 @@ Format to be followed for making changes in this file
 
   The range depends on the Data Type of the macro.
 
-  - − If the data type is of type task priority, then its value should
+  - - If the data type is of type task priority, then its value should
     be an integer in the range of 1 to 255.
-  - − If the data type is an integer, then it can have numbers, characters
+  - - If the data type is an integer, then it can have numbers, characters
     (in case the value is defined using another macro) and arithmetic operations
     (+, -, \*, /).
-  - − If the data type is a function pointer the first character
+  - - If the data type is a function pointer the first character
     should be an alphabet or an underscore. The rest of the string
     can be alphanumeric.
-  - − If the data type is RTEMS Attributes or RTEMS Mode then
+  - - If the data type is RTEMS Attributes or RTEMS Mode then
     the string should be alphanumeric.
-  - − If the data type is RTEMS NAME then the value should be
-    an integer>=0 or RTEMS_BUILD_NAME( ’U’, ’I’, ’1’, ’ ’ )
+  - - If the data type is RTEMS NAME then the value should be
+    an integer>=0 or RTEMS_BUILD_NAME( 'U', 'I', '1', ' ' )
 
 - DEFAULT VALUE
 
   The default value should be in the following formats-
-  Please note that the ’.’ (full stop) is necessary.
+  Please note that the '.' (full stop) is necessary.
 
-  - − In case the value is not defined then:
+  - - In case the value is not defined then:
     This is not defined by default.
-  - − If we know the default value then:
+  - - If we know the default value then:
     The default value is XXX.
-  - − If the default value is BSP Specific then:
+  - - If the default value is BSP Specific then:
     This option is BSP specific.
 
 - DESCRIPTION
@@ -2067,7 +2067,7 @@ the amount of memory reserved for Classic API Message Buffers.
 Calculate Memory for a Single Classic Message API Message Queue
 ---------------------------------------------------------------
 .. index:: CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE
-.. index:: memory for a single message queue’s buffers
+.. index:: memory for a single message queue's buffers
 
 *CONSTANT:*
     ``CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE(max_messages, size_per)``
@@ -4344,7 +4344,7 @@ Enable the Graphics Frame Buffer Device Driver
 **DESCRIPTION:**
 
 ``CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER`` is defined
-if the application wishes to include the BSP’s Frame Buffer Device Driver.
+if the application wishes to include the BSP's Frame Buffer Device Driver.
 
 **NOTES:**
 
diff --git a/c_user/constant_bandwidth_server.rst b/c_user/constant_bandwidth_server.rst
index 6616623..69e2db9 100644
--- a/c_user/constant_bandwidth_server.rst
+++ b/c_user/constant_bandwidth_server.rst
@@ -72,7 +72,7 @@ Handling Periodic Tasks
 -----------------------
 .. index:: CBS periodic tasks
 
-Each task’s execution begins with a default background priority
+Each task's execution begins with a default background priority
 (see the chapter Scheduling Concepts to understand the concept of
 priorities in EDF). Once you decide the tasks should start periodic
 execution, you have two possibilities. Either you use only the Rate
@@ -146,10 +146,10 @@ Attaching Task to a Server
 --------------------------
 
 If a task is attached to a server using ``rtems_cbs_attach_thread``,
-the task’s computation time per period is limited by the server and
+the task's computation time per period is limited by the server and
 the deadline (period) of task is equal to deadline of the server which
 means if you conclude a period using ``rate_monotonic_period``,
-the length of next period is always determined by the server’s property.
+the length of next period is always determined by the server's property.
 
 The task has a guaranteed bandwidth given by the server but should not
 exceed it, otherwise the priority is pulled to background until the
@@ -220,8 +220,8 @@ to avoid overrun.
 Directives
 ==========
 
-This section details the Constant Bandwidth Server’s directives.
-A subsection is dedicated to each of this manager’s directives
+This section details the Constant Bandwidth Server's directives.
+A subsection is dedicated to each of this manager's directives
 and describes the calling sequence, related constants, usage,
 and status codes.
 
@@ -308,7 +308,7 @@ This routine prepares an instance of a constant bandwidth server.
 The input parameter ``rtems_cbs_parameters`` specifies scheduling
 parameters of the server (period and budget). If these are not valid,``RTEMS_CBS_ERROR_INVALID_PARAMETER`` is returned.
 The ``budget_overrun_callback`` is an optional callback function, which is
-invoked in case the server’s budget within one period is exceeded.
+invoked in case the server's budget within one period is exceeded.
 Output parameter ``server_id`` becomes an id of the newly created server.
 If there is not enough memory, the ``RTEMS_CBS_ERROR_NO_MEMORY``
 is returned. If the maximum server count in the system is exceeded,``RTEMS_CBS_ERROR_FULL`` is returned.
@@ -583,7 +583,7 @@ CBS_GET_APPROVED_BUDGET - Get scheduler approved execution time
 
 **DESCRIPTION:**
 
-This directive returns server’s approved budget for subsequent periods.
+This directive returns server's approved budget for subsequent periods.
 
 .. COMMENT: COPYRIGHT (c) 1989-2011.
 
diff --git a/c_user/cpu_usage_statistics.rst b/c_user/cpu_usage_statistics.rst
index bc057c3..743a859 100644
--- a/c_user/cpu_usage_statistics.rst
+++ b/c_user/cpu_usage_statistics.rst
@@ -83,7 +83,7 @@ successive clock ticks, there would be no way to tell that it
 executed at all.
 
 Another thing to keep in mind when looking at idle time, is that
-many systems – especially during debug – have a task providing
+many systems - especially during debug - have a task providing
 some type of debug interface.  It is usually fine to think of the
 total idle time as being the sum of the IDLE task and a debug
 task that will not be included in a production build of an application.
@@ -97,8 +97,8 @@ the CPU usage statistics for all tasks in the system.
 Directives
 ==========
 
-This section details the CPU usage statistics manager’s directives.
-A subsection is dedicated to each of this manager’s directives
+This section details the CPU usage statistics manager's directives.
+A subsection is dedicated to each of this manager's directives
 and describes the calling sequence, related constants, usage,
 and status codes.
 
diff --git a/c_user/dual_ports_memory_manager.rst b/c_user/dual_ports_memory_manager.rst
index 471cefc..5dd59a5 100644
--- a/c_user/dual_ports_memory_manager.rst
+++ b/c_user/dual_ports_memory_manager.rst
@@ -94,8 +94,8 @@ its control block is returned to the DPCB free list.
 Directives
 ==========
 
-This section details the dual-ported memory manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the dual-ported memory manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.
 
diff --git a/c_user/event_manager.rst b/c_user/event_manager.rst
index cfe3cc5..740d127 100644
--- a/c_user/event_manager.rst
+++ b/c_user/event_manager.rst
@@ -116,10 +116,10 @@ the target task, one of the following situations applies:
 
 - Target Task is Blocked Waiting for Events
 
-  - If the waiting task’s input event condition is
+  - If the waiting task's input event condition is
     satisfied, then the task is made ready for execution.
 
-  - If the waiting task’s input event condition is not
+  - If the waiting task's input event condition is not
     satisfied, then the event set is posted but left pending and the
     task remains blocked.
 
@@ -170,8 +170,8 @@ pending then the ``RTEMS_UNSATISFIED`` status code will be returned.
 Directives
 ==========
 
-This section details the event manager’s directives.
-A subsection is dedicated to each of this manager’s directives
+This section details the event manager's directives.
+A subsection is dedicated to each of this manager's directives
 and describes the calling sequence, related constants, usage,
 and status codes.
 
@@ -198,7 +198,7 @@ EVENT_SEND - Send event set to a task
 **DESCRIPTION:**
 
 This directive sends an event set, event_in, to the
-task specified by id.  If a blocked task’s input event condition
+task specified by id.  If a blocked task's input event condition
 is satisfied by this directive, then it will be made ready.  If
 its input event condition is not satisfied, then the events
 satisfied are updated and the events not satisfied are left
diff --git a/c_user/fatal_error.rst b/c_user/fatal_error.rst
index 2c540f1..b4c221a 100644
--- a/c_user/fatal_error.rst
+++ b/c_user/fatal_error.rst
@@ -81,7 +81,7 @@ contains three pieces of information:
 The error type indicator is dependent on the source
 of the error and whether or not the error was internally
 generated by the executive.  If the error was generated
-from an API, then the error code will be of that API’s
+from an API, then the error code will be of that API's
 error or status codes.  The status codes for the RTEMS
 API are in cpukit/rtems/include/rtems/rtems/status.h.  Those
 for the POSIX API can be found in <errno.h>.
@@ -106,8 +106,8 @@ occurred.
 Directives
 ==========
 
-This section details the fatal error manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the fatal error manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.
 
@@ -137,7 +137,7 @@ error extension is defined in the configuration table, then the
 user-defined error extension is called.  If configured and the
 provided FATAL error extension returns, then the RTEMS default
 error handler is invoked.  This directive can be invoked by
-RTEMS or by the user’s application code including initialization
+RTEMS or by the user's application code including initialization
 tasks, other tasks, and ISRs.
 
 **NOTES:**
diff --git a/c_user/glossary.rst b/c_user/glossary.rst
index b9d9c7d..5464bf4 100644
--- a/c_user/glossary.rst
+++ b/c_user/glossary.rst
@@ -142,11 +142,11 @@ Glossary
     peripheral devices used by the application.
 
 :dfn:`directives`
-    RTEMS’ provided routines that provide
+    RTEMS' provided routines that provide
     support mechanisms for real-time applications.
 
 :dfn:`dispatch`
-    The act of loading a task’s context onto
+    The act of loading a task's context onto
     the CPU and transferring control of the CPU to that task.
 
 :dfn:`dormant`
@@ -177,7 +177,7 @@ Glossary
 :dfn:`entry point`
     The address at which a function or task
     begins to execute.  In C, the entry point of a function is the
-    function’s name.
+    function's name.
 
 :dfn:`events`
     A method for task communication and
@@ -339,7 +339,7 @@ Glossary
     Device Driver Table.
 
 :dfn:`manager`
-    A group of related RTEMS’ directives which
+    A group of related RTEMS' directives which
     provide access and control over resources.
 
 :dfn:`memory pool`
@@ -368,7 +368,7 @@ Glossary
     driver, the exact usage of which is driver dependent.
 
 :dfn:`mode`
-    An entry in a task’s control block that is
+    An entry in a task's control block that is
     used to determine if the task allows preemption, timeslicing,
     processing of signals, and the interrupt disable level used by
     the task.
@@ -435,7 +435,7 @@ Glossary
 
 :dfn:`operating system`
     The software which controls all
-    the computer’s resources and provides the base upon which
+    the computer's resources and provides the base upon which
     application programs can be written.
 
 :dfn:`overhead`
@@ -595,7 +595,7 @@ Glossary
 
 :dfn:`resume`
     Removing a task from the suspend state.  If
-    the task’s state is ready following a call to the ``rtems_task_resume``
+    the task's state is ready following a call to the ``rtems_task_resume``
     directive, then the task is available for scheduling.
 
 :dfn:`return code`
@@ -671,7 +671,7 @@ Glossary
 
 :dfn:`signal set`
     A thirty-two bit entity which is used to
-    represent a task’s collection of pending signals and the signals
+    represent a task's collection of pending signals and the signals
     sent to a task.
 
 :dfn:`SMCB`
diff --git a/c_user/index.rst b/c_user/index.rst
index 0b24f90..bef9f30 100644
--- a/c_user/index.rst
+++ b/c_user/index.rst
@@ -1,8 +1,8 @@
 ====================
-RTEMS C User’s Guide
+RTEMS C User's Guide
 ====================
 
-COPYRIGHT © 1988 - 2015.
+COPYRIGHT (c) 1988 - 2015.
 
 On-Line Applications Research Corporation (OAR).
 
diff --git a/c_user/initialization.rst b/c_user/initialization.rst
index d57ffac..e2a823b 100644
--- a/c_user/initialization.rst
+++ b/c_user/initialization.rst
@@ -24,7 +24,7 @@ Initialization Tasks
 .. index:: initialization tasks
 
 Initialization task(s) are the mechanism by which
-RTEMS transfers initial control to the user’s application.
+RTEMS transfers initial control to the user's application.
 Initialization tasks differ from other application tasks in that
 they are defined in the User Initialization Tasks Table and
 automatically created and started by RTEMS as part of its
@@ -211,8 +211,8 @@ application to end multitasking and terminate the system.
 Directives
 ==========
 
-This section details the Initialization Manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the Initialization Manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.
 
diff --git a/c_user/interrupt_manager.rst b/c_user/interrupt_manager.rst
index 5b9d6c3..52f4339 100644
--- a/c_user/interrupt_manager.rst
+++ b/c_user/interrupt_manager.rst
@@ -50,7 +50,7 @@ interrupt occurs, the processor will automatically vector to
 RTEMS.  RTEMS saves and restores all registers which are not
 preserved by the normal C calling convention
 for the target
-processor and invokes the user’s ISR.  The user’s ISR is
+processor and invokes the user's ISR.  The user's ISR is
 responsible for processing the interrupt, clearing the interrupt
 if necessary, and device specific manipulation... index:: rtems_vector_number
 
@@ -80,7 +80,7 @@ servicing.
 To minimize the masking of lower or equal priority
 level interrupts, the ISR should perform the minimum actions
 required to service the interrupt.  Other non-essential actions
-should be handled by application tasks.  Once the user’s ISR has
+should be handled by application tasks.  Once the user's ISR has
 completed, it returns control to the RTEMS interrupt manager
 which will perform task dispatching and restore the registers
 saved before the ISR was invoked.
@@ -119,9 +119,9 @@ RTEMS Interrupt Levels
 Many processors support multiple interrupt levels or
 priorities.  The exact number of interrupt levels is processor
 dependent.  RTEMS internally supports 256 interrupt levels which
-are mapped to the processor’s interrupt levels.  For specific
+are mapped to the processor's interrupt levels.  For specific
 information on the mapping between RTEMS and the target
-processor’s interrupt levels, refer to the Interrupt Processing
+processor's interrupt levels, refer to the Interrupt Processing
 chapter of the Applications Supplement document for a specific
 target processor.
 
@@ -157,10 +157,10 @@ The ``rtems_interrupt_catch``
 directive establishes an ISR for
 the system.  The address of the ISR and its associated CPU
 vector number are specified to this directive.  This directive
-installs the RTEMS interrupt wrapper in the processor’s
-Interrupt Vector Table and the address of the user’s ISR in the
-RTEMS’ Vector Table.  This directive returns the previous
-contents of the specified vector in the RTEMS’ Vector Table.
+installs the RTEMS interrupt wrapper in the processor's
+Interrupt Vector Table and the address of the user's ISR in the
+RTEMS' Vector Table.  This directive returns the previous
+contents of the specified vector in the RTEMS' Vector Table.
 
 Directives Allowed from an ISR
 ------------------------------
@@ -253,8 +253,8 @@ made from an ISR:
 Directives
 ==========
 
-This section details the interrupt manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the interrupt manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.
 
@@ -288,7 +288,7 @@ routine (ISR) for the specified interrupt vector number.  The``new_isr_handler``
 The entry point of the previous ISR for the specified vector is
 returned in ``old_isr_handler``.
 
-To release an interrupt vector, pass the old handler’s address obtained
+To release an interrupt vector, pass the old handler's address obtained
 when the vector was first capture.
 
 **NOTES:**
diff --git a/c_user/io_manager.rst b/c_user/io_manager.rst
index f870580..cf24310 100644
--- a/c_user/io_manager.rst
+++ b/c_user/io_manager.rst
@@ -41,7 +41,7 @@ Device Driver Table
 
 Each application utilizing the RTEMS I/O manager must specify the
 address of a Device Driver Table in its Configuration Table. This table
-contains each device driver’s entry points that is to be initialised by
+contains each device driver's entry points that is to be initialised by
 RTEMS during initialization.  Each device driver may contain the
 following entry points:
 
@@ -59,8 +59,8 @@ following entry points:
 
 If the device driver does not support a particular
 entry point, then that entry in the Configuration Table should
-be NULL.  RTEMS will return``RTEMS_SUCCESSFUL`` as the executive’s and
-zero (0) as the device driver’s return code for these device
+be NULL.  RTEMS will return``RTEMS_SUCCESSFUL`` as the executive's and
+zero (0) as the device driver's return code for these device
 driver entry points.
 
 Applications can register and unregister drivers with the RTEMS I/O
@@ -75,9 +75,9 @@ Major and Minor Device Numbers
 .. index:: major device number
 .. index:: minor device number
 
-Each call to the I/O manager must provide a device’s
+Each call to the I/O manager must provide a device's
 major and minor numbers as arguments.  The major number is the
-index of the requested driver’s entry points in the Device
+index of the requested driver's entry points in the Device
 Driver Table, and is used to select a specific device driver.
 The exact usage of the minor number is driver specific, but is
 commonly used to distinguish between a number of devices
@@ -224,8 +224,8 @@ and the underlying device driver entry points.
 Directives
 ==========
 
-This section details the I/O manager’s directives.  A
-subsection is dedicated to each of this manager’s directives and
+This section details the I/O manager's directives.  A
+subsection is dedicated to each of this manager's directives and
 describes the calling sequence, related constants, usage, and
 status codes.
 
@@ -258,7 +258,7 @@ IO_REGISTER_DRIVER - Register a device driver
 
 This directive attempts to add a new device driver to the Device Driver
 Table. The user can specify a specific major device number via the
-directive’s ``major`` parameter, or let the registration routine find
+directive's ``major`` parameter, or let the registration routine find
 the next available major device number by specifing a major number of``0``. The selected major device number is returned via the``registered_major`` directive parameter. The directive automatically
 allocation major device numbers from the highest value down.
 
diff --git a/c_user/key_concepts.rst b/c_user/key_concepts.rst
index c5ee56f..9f4c5ea 100644
--- a/c_user/key_concepts.rst
+++ b/c_user/key_concepts.rst
@@ -26,10 +26,10 @@ re-usable "building block" routines.
 All objects are created on the local node as required
 by the application and have an RTEMS assigned ID.  All objects
 have a user-assigned name.  Although a relationship exists
-between an object’s name and its RTEMS assigned ID, the name and
+between an object's name and its RTEMS assigned ID, the name and
 ID are not identical.  Object names are completely arbitrary and
 selected by the user as a meaningful "tag" which may commonly
-reflect the object’s use in the application.  Conversely, object
+reflect the object's use in the application.  Conversely, object
 IDs are designed to facilitate efficient object manipulation by
 the executive.
 
@@ -149,7 +149,7 @@ Object ID Description
 
 The components of an object ID make it possible
 to quickly locate any object in even the most complicated
-multiprocessor system.  Object ID’s are associated with an
+multiprocessor system.  Object ID's are associated with an
 object by RTEMS when the object is created and the corresponding
 ID is returned by the appropriate object create directive.  The
 object ID is required as input to all directives involving
@@ -157,7 +157,7 @@ objects, except those which create an object or obtain the ID of
 an object.
 
 The object identification directives can be used to
-dynamically obtain a particular object’s ID given its name.
+dynamically obtain a particular object's ID given its name.
 This mapping is accomplished by searching the name table
 associated with this object type.  If the name is non-unique,
 then the ID associated with the first occurrence of the name
@@ -190,10 +190,10 @@ as follows:.. index:: obtaining class from object ID
 An object control block is a data structure defined
 by RTEMS which contains the information necessary to manage a
 particular object type.  For efficiency reasons, the format of
-each object type’s control block is different.  However, many of
+each object type's control block is different.  However, many of
 the fields are similar in function.  The number of each type of
 control block is application dependent and determined by the
-values specified in the user’s Configuration Table.  An object
+values specified in the user's Configuration Table.  An object
 control block is allocated at object create time and freed when
 the object is deleted.  With the exception of user extension
 routines, object control blocks are not directly manipulated by
@@ -220,7 +220,7 @@ Most RTEMS managers can be used to provide some form
 of communication and/or synchronization.  However, managers
 dedicated specifically to communication and synchronization
 provide well established mechanisms which directly map to the
-application’s varying needs.  This level of flexibility allows
+application's varying needs.  This level of flexibility allows
 the application designer to match the features of a particular
 manager with the complexity of communication and synchronization
 required.  The following managers were specifically designed for
@@ -276,9 +276,9 @@ the clock granularity is large.
 The rate monotonic scheduling algorithm is a hard
 real-time scheduling methodology.  This methodology provides
 rules which allows one to guarantee that a set of independent
-periodic tasks will always meet their deadlines – even under
+periodic tasks will always meet their deadlines - even under
 transient overload conditions.  The rate monotonic manager
-provides directives built upon the Clock Manager’s interval
+provides directives built upon the Clock Manager's interval
 timer support routines.
 
 Interval timing is not sufficient for the many
@@ -286,7 +286,7 @@ applications which require that time be kept in wall time or
 true calendar form.  Consequently, RTEMS maintains the current
 date and time.  This allows selected time operations to be
 scheduled at an actual calendar date and time.  For example, a
-task could request to delay until midnight on New Year’s Eve
+task could request to delay until midnight on New Year's Eve
 before lowering the ball at Times Square.
 The data type ``rtems_time_of_day`` is used to specify
 calendar time in RTEMS services.
@@ -307,7 +307,7 @@ RTEMS memory management facilities can be grouped
 into two classes: dynamic memory allocation and address
 translation.  Dynamic memory allocation is required by
 applications whose memory requirements vary through the
-application’s course of execution.  Address translation is
+application's course of execution.  Address translation is
 needed by applications which share memory with another CPU or an
 intelligent Input/Output processor.  The following RTEMS
 managers provide facilities to manage memory:
diff --git a/c_user/message_manager.rst b/c_user/message_manager.rst
index 42211e1..57401bc 100644
--- a/c_user/message_manager.rst
+++ b/c_user/message_manager.rst
@@ -152,7 +152,7 @@ Receiving a Message
 The ``rtems_message_queue_receive`` directive attempts to
 retrieve a message from the specified message queue.  If at
 least one message is in the queue, then the message is removed
-from the queue, copied to the caller’s message buffer, and
+from the queue, copied to the caller's message buffer, and
 returned immediately along with the length of the message.  When
 messages are unavailable, one of the following situations
 applies:
@@ -167,7 +167,7 @@ applies:
   wait before returning with an error status.
 
 If the task waits for a message, then it is placed in
-the message queue’s task wait queue in either FIFO or task
+the message queue's task wait queue in either FIFO or task
 priority order.  All tasks waiting on a message queue are
 returned an error code when the message queue is deleted.
 
@@ -177,13 +177,13 @@ Sending a Message
 Messages can be sent to a queue with the``rtems_message_queue_send`` and``rtems_message_queue_urgent`` directives.  These
 directives work identically when tasks are waiting to receive a
 message.  A task is removed from the task waiting queue,
-unblocked,  and the message is copied to a waiting task’s
+unblocked,  and the message is copied to a waiting task's
 message buffer.
 
 When no tasks are waiting at the queue,``rtems_message_queue_send`` places the
 message at the rear of the message queue, while``rtems_message_queue_urgent`` places the message at the
 front of the queue.  The message is copied to a message buffer
-from this message queue’s buffer pool and then placed in the
+from this message queue's buffer pool and then placed in the
 message queue.  Neither directive can successfully send a
 message to a message queue which has a full queue of pending
 messages.
@@ -194,7 +194,7 @@ Broadcasting a Message
 The ``rtems_message_queue_broadcast`` directive sends the same
 message to every task waiting on the specified message queue as
 an atomic operation.  The message is copied to each waiting
-task’s message buffer and each task is unblocked.  The number of
+task's message buffer and each task is unblocked.  The number of
 tasks which were unblocked is returned to the caller.
 
 Deleting a Message Queue
@@ -202,20 +202,20 @@ Deleting a Message Queue
 
 The ``rtems_message_queue_delete`` directive removes a message
 queue from the system and frees its control block as well as the
-memory associated with this message queue’s message buffer pool.
+memory associated with this message queue's message buffer pool.
 A message queue can be deleted by any local task that knows the
-message queue’s ID.  As a result of this directive, all tasks
+message queue's ID.  As a result of this directive, all tasks
 blocked waiting to receive a message from the message queue will
 be readied and returned a status code which indicates that the
 message queue was deleted.  Any subsequent references to the
-message queue’s name and ID are invalid.  Any messages waiting
+message queue's name and ID are invalid.  Any messages waiting
 at the message queue are also deleted and deallocated.
 
 Directives
 ==========
 
-This section details the message manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the message manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.
 
@@ -284,7 +284,7 @@ Message queues should not be made global unless
 remote tasks must interact with the created message queue.  This
 is to avoid the system overhead incurred by the creation of a
 global message queue.  When a global message queue is created,
-the message queue’s name and id must be transmitted to every
+the message queue's name and id must be transmitted to every
 node in the system for insertion in the local copy of the global
 object table.
 
@@ -422,16 +422,16 @@ MESSAGE_QUEUE_SEND - Put message at rear of a queue
 ``RTEMS_INVALID_SIZE`` - invalid message size
 ``RTEMS_INVALID_ADDRESS`` - ``buffer`` is NULL
 ``RTEMS_UNSATISFIED`` - out of message buffers
-``RTEMS_TOO_MANY`` - queue’s limit has been reached
+``RTEMS_TOO_MANY`` - queue's limit has been reached
 
 **DESCRIPTION:**
 
 This directive sends the message buffer of size bytes
 in length to the queue specified by id.  If a task is waiting at
-the queue, then the message is copied to the waiting task’s
+the queue, then the message is copied to the waiting task's
 buffer and the task is unblocked. If no tasks are waiting at the
 queue, then the message is copied to a message buffer which is
-obtained from this message queue’s message buffer pool.  The
+obtained from this message queue's message buffer pool.  The
 message buffer is then placed at the rear of the queue.
 
 **NOTES:**
@@ -472,16 +472,16 @@ MESSAGE_QUEUE_URGENT - Put message at front of a queue
 ``RTEMS_INVALID_SIZE`` - invalid message size
 ``RTEMS_INVALID_ADDRESS`` - ``buffer`` is NULL
 ``RTEMS_UNSATISFIED`` - out of message buffers
-``RTEMS_TOO_MANY`` - queue’s limit has been reached
+``RTEMS_TOO_MANY`` - queue's limit has been reached
 
 **DESCRIPTION:**
 
 This directive sends the message buffer of size bytes
 in length to the queue specified by id.  If a task is waiting on
-the queue, then the message is copied to the task’s buffer and
+the queue, then the message is copied to the task's buffer and
 the task is unblocked.  If no tasks are waiting on the queue,
 then the message is copied to a message buffer which is obtained
-from this message queue’s message buffer pool.  The message
+from this message queue's message buffer pool.  The message
 buffer is then placed at the front of the queue.
 
 **NOTES:**
@@ -530,7 +530,7 @@ MESSAGE_QUEUE_BROADCAST - Broadcast N messages to a queue
 This directive causes all tasks that are waiting at
 the queue specified by id to be unblocked and sent the message
 contained in buffer.  Before a task is unblocked, the message
-buffer of size byes in length is copied to that task’s message
+buffer of size byes in length is copied to that task's message
 buffer.  The number of tasks that were unblocked is returned in
 count.
 
diff --git a/c_user/multiprocessing.rst b/c_user/multiprocessing.rst
index dfd3324..1c0ba04 100644
--- a/c_user/multiprocessing.rst
+++ b/c_user/multiprocessing.rst
@@ -45,7 +45,7 @@ Background
 RTEMS makes no assumptions regarding the connection
 media or topology of a multiprocessor system.  The tasks which
 compose a particular application can be spread among as many
-processors as needed to satisfy the application’s timing
+processors as needed to satisfy the application's timing
 requirements.  The application tasks can interact using a subset
 of the RTEMS directives as if they were on the same processor.
 These directives allow application tasks to exchange data,
@@ -198,9 +198,9 @@ Proxies
 A proxy is an RTEMS data structure which resides on a
 remote node and is used to represent a task which must block as
 part of a remote operation. This action can occur as part of the``rtems_semaphore_obtain`` and``rtems_message_queue_receive`` directives.  If the
-object were local, the task’s control block would be available
+object were local, the task's control block would be available
 for modification to indicate it was blocking on a message queue
-or semaphore.  However, the task’s control block resides only on
+or semaphore.  However, the task's control block resides only on
 the same node as the task.  As a result, the remote node must
 allocate a proxy to represent the task until it can be readied.
 
@@ -241,7 +241,7 @@ packet within an envelope which contains the information needed
 by the MPCI layer.  The number of packets available is dependent
 on the MPCI layer implementation... index:: MPCI entry points
 
-The entry points to the routines in the user’s MPCI
+The entry points to the routines in the user's MPCI
 layer should be placed in the Multiprocessor Communications
 Interface Table.  The user must provide entry points for each of
 the following table entries in a multiprocessor system:
@@ -296,7 +296,7 @@ following prototype:.. index:: rtems_mpci_entry
     rtems_configuration_table \*configuration
     );
 
-where configuration is the address of the user’s
+where configuration is the address of the user's
 Configuration Table.  Operations on global objects cannot be
 performed until this component is invoked.  The INITIALIZATION
 component is invoked only once in the life of any system.  If
@@ -455,7 +455,7 @@ Other issues which commonly impact the design of
 shared data structures include the representation of floating
 point numbers, bit fields, decimal data, and character strings.
 In addition, the representation method for negative integers
-could be one’s or two’s complement.  These factors combine to
+could be one's or two's complement.  These factors combine to
 increase the complexity of designing and manipulating data
 structures shared between processors.
 
@@ -495,7 +495,7 @@ Directives
 
 This section details the additional directives
 required to support RTEMS in a multiprocessor configuration.  A
-subsection is dedicated to each of this manager’s directives and
+subsection is dedicated to each of this manager's directives and
 describes the calling sequence, related constants, usage, and
 status codes.
 
diff --git a/c_user/overview.rst b/c_user/overview.rst
index 6b4d125..80ad8da 100644
--- a/c_user/overview.rst
+++ b/c_user/overview.rst
@@ -270,7 +270,7 @@ that is created.  Thus the more RTEMS objects an application
 needs, the more memory that must be reserved.  See `Configuring a System`_.
 
 RTEMS utilizes memory for both code and data space.
-Although RTEMS’ data space must be in RAM, its code space can be
+Although RTEMS' data space must be in RAM, its code space can be
 located in either ROM or RAM.
 
 Audience
@@ -288,9 +288,9 @@ understand the material presented.  However, because of the
 similarity of the Ada and C RTEMS implementations, users will
 find that the use and behavior of the two implementations is
 very similar.  A working knowledge of the target processor is
-helpful in understanding some of RTEMS’ features.  A thorough
+helpful in understanding some of RTEMS' features.  A thorough
 understanding of the executive cannot be obtained without
-studying the entire manual because many of RTEMS’ concepts and
+studying the entire manual because many of RTEMS' concepts and
 features are interrelated.  Experienced RTEMS users will find
 that the manual organization facilitates its use as a reference
 document.
@@ -450,7 +450,7 @@ Chapter 26:
 Chapter 27:
     Object Services: presents a collection of helper services useful
     when manipulating RTEMS objects. These include methods to assist
-    in obtaining an object’s name in printable form. Additional services
+    in obtaining an object's name in printable form. Additional services
     are provided to decompose an object Id and determine which API
     and object class it belongs to.
 
diff --git a/c_user/partition_manager.rst b/c_user/partition_manager.rst
index c411a13..8ea18d3 100644
--- a/c_user/partition_manager.rst
+++ b/c_user/partition_manager.rst
@@ -32,7 +32,7 @@ divided into fixed-size buffers that can be dynamically
 allocated and deallocated... index:: buffers, definition
 
 Partitions are managed and maintained as a list of
-buffers.  Buffers are obtained from the front of the partition’s
+buffers.  Buffers are obtained from the front of the partition's
 free buffer chain and returned to the rear of the same chain.
 When a buffer is on the free buffer chain, RTEMS uses two
 pointers of memory from each buffer as the free buffer chain.
@@ -70,7 +70,7 @@ Creating a Partition
 --------------------
 
 The ``rtems_partition_create`` directive creates a partition
-with a user-specified name.  The partition’s name, starting
+with a user-specified name.  The partition's name, starting
 address, length and buffer size are all specified to the``rtems_partition_create`` directive.
 RTEMS allocates a Partition Control
 Block (PTCB) from the PTCB free list.  This data structure is
@@ -104,7 +104,7 @@ become available.
 Releasing a Buffer
 ------------------
 
-Buffers are returned to a partition’s free buffer
+Buffers are returned to a partition's free buffer
 chain with the ``rtems_partition_return_buffer`` directive.  This
 directive returns an error status code if the returned buffer
 was not previously allocated from this partition.
@@ -121,8 +121,8 @@ task attempting to do so will be returned an error status code.
 Directives
 ==========
 
-This section details the partition manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the partition manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.
 
@@ -199,7 +199,7 @@ local node.  The memory space used for the partition must reside
 in shared memory. Partitions should not be made global unless
 remote tasks must interact with the partition.  This is to avoid
 the overhead incurred by the creation of a global partition.
-When a global partition is created, the partition’s name and id
+When a global partition is created, the partition's name and id
 must be transmitted to every node in the system for insertion in
 the local copy of the global object table.
 
diff --git a/c_user/pci_library.rst b/c_user/pci_library.rst
index 12acfd4..0512b45 100644
--- a/c_user/pci_library.rst
+++ b/c_user/pci_library.rst
@@ -240,7 +240,7 @@ Peripheral Configuration
 
 On systems where a peripheral PCI device needs to access other PCI devices than
 the host the peripheral configuration approach may be handy. Most PCI devices
-answers on the PCI host’s requests and start DMA accesses into the Hosts memory,
+answers on the PCI host's requests and start DMA accesses into the Hosts memory,
 however in some complex systems PCI devices may want to access other devices
 on the same bus or at another PCI bus.
 
@@ -420,7 +420,7 @@ use the standard RTEMS interrupt functions directly.
 PCI Shell command
 -----------------
 
-The RTEMS shell has a PCI command ’pci’ which makes it possible to read/write
+The RTEMS shell has a PCI command 'pci' which makes it possible to read/write
 configuration space, print the current PCI configuration and print out a
 configuration C-file for the static or peripheral library.
 
diff --git a/c_user/preface.rst b/c_user/preface.rst
index 97bd805..ce828b0 100644
--- a/c_user/preface.rst
+++ b/c_user/preface.rst
@@ -45,7 +45,7 @@ multiple real-time executive implementations.  This interface
 includes both the source code interfaces and run-time behavior
 as seen by a real-time application.  It does not include the
 details of how a kernel implements these functions.  The
-standard’s goal is to serve as a complete definition of external
+standard's goal is to serve as a complete definition of external
 interfaces so that application code that conforms to these
 interfaces will execute properly in all real-time executive
 environments.  With the use of a standards compliant executive,
@@ -68,8 +68,8 @@ of which processor the object and the accessing task reside.
 
 The acceptance of a standard for real-time executives
 will produce the same advantages enjoyed from the push for UNIX
-standardization by AT&T’s System V Interface Definition and
-IEEE’s POSIX efforts.  A compliant multiprocessing executive
+standardization by AT&T's System V Interface Definition and
+IEEE's POSIX efforts.  A compliant multiprocessing executive
 will allow close coupling between UNIX systems and real-time
 executives to provide the many benefits of the UNIX development
 environment to be applied to real-time software development.
diff --git a/c_user/rate_monotonic_manager.rst b/c_user/rate_monotonic_manager.rst
index c22cd00..5bd3b1b 100644
--- a/c_user/rate_monotonic_manager.rst
+++ b/c_user/rate_monotonic_manager.rst
@@ -115,11 +115,11 @@ and it averaged 11 milliseconds, then application requirements
 are not being met.
 
 The information reported can be used to determine the "hot spots"
-in the application.  Given a period’s id, the user can determine
+in the application.  Given a period's id, the user can determine
 the length of that period.  From that information and the CPU usage,
 the user can calculate the percentage of CPU time consumed by that
 periodic task.  For example, a task executing for 20 milliseconds
-every 200 milliseconds is consuming 10 percent of the processor’s
+every 200 milliseconds is consuming 10 percent of the processor's
 execution time.  This is usually enough to make it a good candidate
 for optimization.
 
@@ -142,9 +142,9 @@ characterized by the length of their period and execution time.
 The period and execution time of a task can be used to determine
 the processor utilization for that task.  Processor utilization
 is the percentage of processor time used and can be calculated
-on a per-task or system-wide basis.  Typically, the task’s
+on a per-task or system-wide basis.  Typically, the task's
 worst-case execution time will be less than its period.  For
-example, a periodic task’s requirements may state that it should
+example, a periodic task's requirements may state that it should
 execute for 10 milliseconds every 100 milliseconds.  Although
 the execution time may be the average, worst, or best case, the
 worst-case execution time is more appropriate for use when
@@ -178,7 +178,7 @@ deadlines.  RMS provides a set of rules which can be used to
 perform a guaranteed schedulability analysis for a task set.
 This analysis determines whether a task set is schedulable under
 worst-case conditions and emphasizes the predictability of the
-system’s behavior.  It has been proven that:
+system's behavior.  It has been proven that:
 
 - *RMS is an optimal static priority algorithm for
   scheduling independent, preemptible, periodic tasks
@@ -191,13 +191,13 @@ analysis on the processor utilization level below which all
 deadlines can be met.
 
 RMS calls for the static assignment of task
-priorities based upon their period.  The shorter a task’s
+priorities based upon their period.  The shorter a task's
 period, the higher its priority.  For example, a task with a 1
 millisecond period has higher priority than a task with a 100
 millisecond period.  If two tasks have the same period, then RMS
 does not distinguish between the tasks.  However, RTEMS
 specifies that when given tasks of equal priority, the task
-which has been ready longest will execute first.  RMS’s priority
+which has been ready longest will execute first.  RMS's priority
 assignment scheme does not provide one with exact numeric values
 for task priorities.  For example, consider the following task
 set and priority assignments:
@@ -345,7 +345,7 @@ quite easy to ensure.  By having a non-preemptible user
 initialization task, all application tasks, regardless of
 priority, can be created and started before the initialization
 deletes itself.  This technique ensures that all tasks begin to
-compete for execution time at the same instant – when the user
+compete for execution time at the same instant - when the user
 initialization task deletes itself.
 
 First Deadline Rule Example
@@ -426,7 +426,7 @@ Another assumption is that the tasks are independent.
 This means that the tasks do not wait for one another or
 contend for resources.  This assumption can be relaxed by
 accounting for the amount of time a task spends waiting to
-acquire resources.  Similarly, each task’s execution time must
+acquire resources.  Similarly, each task's execution time must
 account for any I/O performed and any RTEMS directive calls.
 
 In addition, the assumptions did not account for the
@@ -517,7 +517,7 @@ Obtaining the Status of a Period
 If the ``rtems_rate_monotonic_period`` directive is invoked
 with a period of ``RTEMS_PERIOD_STATUS`` ticks, the current
 state of the specified rate monotonic period will be returned.  The following
-table details the relationship between the period’s status and
+table details the relationship between the period's status and
 the directive status code returned by the``rtems_rate_monotonic_period``
 directive:
 
@@ -544,7 +544,7 @@ Deleting a Rate Monotonic Period
 The ``rtems_rate_monotonic_delete`` directive is used to delete
 a rate monotonic period.  If the period is running and has not
 expired, the period is automatically canceled.  The rate
-monotonic period’s control block is returned to the PCB free
+monotonic period's control block is returned to the PCB free
 list when it is deleted.  A rate monotonic period can be deleted
 by a task other than the task which created the period.
 
@@ -674,8 +674,8 @@ will delete the rate monotonic periods and itself.
 Directives
 ==========
 
-This section details the rate monotonic manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the rate monotonic manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.
 
@@ -899,7 +899,7 @@ the rate monotonic period id in the following data structure:.. index:: rtems_ra
 
 A configure time option can be used to select whether the time information is
 given in ticks or seconds and nanoseconds.  The default is seconds and
-nanoseconds.  If the period’s state is ``RATE_MONOTONIC_INACTIVE``, both
+nanoseconds.  If the period's state is ``RATE_MONOTONIC_INACTIVE``, both
 time values will be set to 0.  Otherwise, both time values will contain
 time information since the last invocation of the``rtems_rate_monotonic_period`` directive.  More
 specifically, the ticks_since_last_period value contains the elapsed time
diff --git a/c_user/red_black_trees.rst b/c_user/red_black_trees.rst
index c4cfc12..35c8db9 100644
--- a/c_user/red_black_trees.rst
+++ b/c_user/red_black_trees.rst
@@ -21,21 +21,21 @@ heap memory. The Red-Black Tree API provided by RTEMS is:
 
 - ``rtems_rtems_rbtree_initialize_empty`` - initialize the red-black tree as empty
 
-- ``rtems_rtems_rbtree_set_off_tree`` - Clear a node’s links
+- ``rtems_rtems_rbtree_set_off_tree`` - Clear a node's links
 
-- ``rtems_rtems_rbtree_root`` - Return the red-black tree’s root node
+- ``rtems_rtems_rbtree_root`` - Return the red-black tree's root node
 
-- ``rtems_rtems_rbtree_min`` - Return the red-black tree’s minimum node
+- ``rtems_rtems_rbtree_min`` - Return the red-black tree's minimum node
 
-- ``rtems_rtems_rbtree_max`` - Return the red-black tree’s maximum node
+- ``rtems_rtems_rbtree_max`` - Return the red-black tree's maximum node
 
-- ``rtems_rtems_rbtree_left`` - Return a node’s left child node
+- ``rtems_rtems_rbtree_left`` - Return a node's left child node
 
-- ``rtems_rtems_rbtree_right`` - Return a node’s right child node
+- ``rtems_rtems_rbtree_right`` - Return a node's right child node
 
-- ``rtems_rtems_rbtree_parent`` - Return a node’s parent node
+- ``rtems_rtems_rbtree_parent`` - Return a node's parent node
 
-- ``rtems_rtems_rbtree_are_nodes_equal`` - Are the node’s equal ?
+- ``rtems_rtems_rbtree_are_nodes_equal`` - Are the node's equal ?
 
 - ``rtems_rtems_rbtree_is_empty`` - Is the red-black tree empty ?
 
@@ -85,8 +85,8 @@ A red-black tree is made up from nodes that orginate from a red-black tree contr
 object. A node is of type ``rtems_rtems_rbtree_node``. The node
 is designed to be part of a user data structure. To obtain the encapsulating
 structure users can use the ``RTEMS_CONTAINER_OF`` macro.
-The node can be placed anywhere within the user’s structure and the macro will
-calculate the structure’s address from the node’s address.
+The node can be placed anywhere within the user's structure and the macro will
+calculate the structure's address from the node's address.
 
 Controls
 --------
diff --git a/c_user/region_manager.rst b/c_user/region_manager.rst
index 1c9bbc0..0b4b939 100644
--- a/c_user/region_manager.rst
+++ b/c_user/region_manager.rst
@@ -47,12 +47,12 @@ Regions are organized as doubly linked chains of
 variable sized memory blocks.  Memory requests are allocated
 using a first-fit algorithm.  If available, the requester
 receives the number of bytes requested (rounded up to the next
-page size).  RTEMS requires some overhead from the region’s
+page size).  RTEMS requires some overhead from the region's
 memory for each segment that is allocated.  Therefore, an
 application should only modify the memory of a segment that has
 been obtained from the region.  The application should NOT
 modify the memory outside of any obtained segments and within
-the region’s boundaries while the region is currently active in
+the region's boundaries while the region is currently active in
 the system.
 
 Upon return to the region, the free block is
@@ -178,7 +178,7 @@ following situations applies:
   wait before returning with an error status code.
 
 If the task waits for the segment, then it is placed
-in the region’s task wait queue in either FIFO or task priority
+in the region's task wait queue in either FIFO or task priority
 order.  All tasks waiting on a region are returned an error when
 the message queue is deleted.
 
@@ -190,7 +190,7 @@ unallocated neighbors to form the largest possible segment.  The
 first task on the wait queue is examined to determine if its
 segment request can now be satisfied.  If so, it is given a
 segment and unblocked.  This process is repeated until the first
-task’s segment request cannot be satisfied.
+task's segment request cannot be satisfied.
 
 Obtaining the Size of a Segment
 -------------------------------
@@ -226,8 +226,8 @@ a status code which indicates that the region was deleted.
 Directives
 ==========
 
-This section details the region manager’s directives.
-A subsection is dedicated to each of this manager’s directives
+This section details the region manager's directives.
+A subsection is dedicated to each of this manager's directives
 and describes the calling sequence, related constants, usage,
 and status codes.
 
@@ -448,7 +448,7 @@ If the calling task chooses to return immediately and
 a segment large enough is not available, then an error code
 indicating this fact is returned.  If the calling task chooses
 to wait for the segment and a segment large enough is not
-available, then the calling task is placed on the region’s
+available, then the calling task is placed on the region's
 segment wait queue and blocked.  If the region was created with
 the ``RTEMS_PRIORITY`` option, then the calling
 task is inserted into the
@@ -465,7 +465,7 @@ calling task will wait forever.
 
 The actual length of the allocated segment may be
 larger than the requested size because a segment size is always
-a multiple of the region’s page size.
+a multiple of the region's page size.
 
 The following segment acquisition option constants
 are defined by RTEMS:
@@ -507,7 +507,7 @@ merged with its neighbors to form the largest possible segment.
 The first task on the wait queue is examined to determine if its
 segment request can now be satisfied.  If so, it is given a
 segment and unblocked.  This process is repeated until the first
-task’s segment request cannot be satisfied.
+task's segment request cannot be satisfied.
 
 **NOTES:**
 
@@ -552,7 +552,7 @@ This directive obtains the size in bytes of the specified segment.
 
 The actual length of the allocated segment may be
 larger than the requested size because a segment size is always
-a multiple of the region’s page size.
+a multiple of the region's page size.
 
 REGION_RESIZE_SEGMENT - Change size of a segment
 ------------------------------------------------
diff --git a/c_user/rtems_data_types.rst b/c_user/rtems_data_types.rst
index 9d3a51f..83e9fe2 100644
--- a/c_user/rtems_data_types.rst
+++ b/c_user/rtems_data_types.rst
@@ -49,13 +49,13 @@ data types in alphabetical order:
 
   ``rtems_context`` is the CPU dependent
   data structure used to manage the integer and system
-  register portion of each task’s context.
+  register portion of each task's context.
 
 - .. index:: rtems_context_fp
 
   ``rtems_context_fp`` is the CPU dependent
   data structure used to manage the floating point portion of
-  each task’s context.
+  each task's context.
 
 - .. index:: rtems_device_driver
 
diff --git a/c_user/scheduling_concepts.rst b/c_user/scheduling_concepts.rst
index 56ddc46..d5b261e 100644
--- a/c_user/scheduling_concepts.rst
+++ b/c_user/scheduling_concepts.rst
@@ -12,10 +12,10 @@ provide immediate response to specific external events, particularly
 the necessity of scheduling tasks to run within a specified time limit
 after the occurrence of an event.  For example, software embedded in
 life-support systems used to monitor hospital patients must take instant
-action if a change in the patient’s status is detected.
+action if a change in the patient's status is detected.
 
 The component of RTEMS responsible for providing this capability is
-appropriately called the scheduler.  The scheduler’s sole purpose is
+appropriately called the scheduler.  The scheduler's sole purpose is
 to allocate the all important resource of processor time to the various
 tasks competing for attention.
 
@@ -175,7 +175,7 @@ Constant Bandwidth Server Scheduling (CBS)
 
 This is an alternative scheduler in RTEMS for single core applications.
 The CBS is a budget aware extension of EDF scheduler. The main goal of this
-scheduler is to ensure temporal isolation of tasks meaning that a task’s
+scheduler is to ensure temporal isolation of tasks meaning that a task's
 execution in terms of meeting deadlines must not be influenced by other
 tasks as if they were run on multiple independent processors.
 
@@ -232,7 +232,7 @@ Task Priority and Scheduling
 
 The most significant task scheduling modification mechanism is the ability
 for the user to assign a priority level to each individual task when it
-is created and to alter a task’s priority at run-time.  RTEMS supports
+is created and to alter a task's priority at run-time.  RTEMS supports
 up to 255 priority levels.  Level 255 is the lowest priority and level
 1 is the highest.
 
@@ -260,7 +260,7 @@ mode flag (``RTEMS_TIMESLICE_MASK``).  If timeslicing is
 enabled for a task (``RTEMS_TIMESLICE``), then RTEMS will
 limit the amount of time the task can execute before the processor is
 allocated to another task.  Each tick of the real-time clock reduces
-the currently running task’s timeslice.  When the execution time equals
+the currently running task's timeslice.  When the execution time equals
 the timeslice, RTEMS will dispatch another task of the same priority
 to execute.  If there are no other tasks of the same priority ready to
 execute, then the current task is allocated an additional timeslice and
@@ -288,14 +288,14 @@ from the task currently using it.  This involves a concept
 called a context switch.  To perform a context switch, the
 dispatcher saves the context of the current task and restores
 the context of the task which has been allocated to the
-processor.  Saving and restoring a task’s context is the
+processor.  Saving and restoring a task's context is the
 storing/loading of all the essential information about a task to
 enable it to continue execution without any effects of the
-interruption.  For example, the contents of a task’s register
+interruption.  For example, the contents of a task's register
 set must be the same when it is given the processor as they were
 when it was taken away.  All of the information that must be
 saved or restored for a context switch is located either in the
-TCB or on the task’s stacks.
+TCB or on the task's stacks.
 
 Tasks that utilize a numeric coprocessor and are created with the``RTEMS_FLOATING_POINT`` attribute require additional
 operations during a context switch.  These additional operations
@@ -394,7 +394,7 @@ A task enters the blocked state due to any of the following conditions:
 
 - The running task issues a ``rtems_region_get_segment``
   directive with the wait option and there is not an available segment large
-  enough to satisfy the task’s request.
+  enough to satisfy the task's request.
 
 A blocked task may also be suspended.  Therefore, both the suspension
 and the blocking condition must be removed before the task becomes ready
@@ -432,7 +432,7 @@ to any of the following conditions:
 - A running task issues a ``rtems_region_return_segment``
   directive which releases a segment to the region on which the blocked task
   is waiting and a resulting segment is large enough to satisfy
-  the task’s request.
+  the task's request.
 
 - A rate monotonic period expires for a task which blocked
   by a call to the ``rtems_rate_monotonic_period`` directive.
diff --git a/c_user/semaphore_manager.rst b/c_user/semaphore_manager.rst
index 38f1a60..4997bf3 100644
--- a/c_user/semaphore_manager.rst
+++ b/c_user/semaphore_manager.rst
@@ -125,7 +125,7 @@ discipline.   When a task of higher priority than the task
 holding the semaphore blocks, the priority of the task holding
 the semaphore is increased to that of the blocking task.  When
 the task holding the task completely releases the binary
-semaphore (i.e. not for a nested release), the holder’s priority
+semaphore (i.e. not for a nested release), the holder's priority
 is restored to the value it had before any higher priority was
 inherited.
 
@@ -159,7 +159,7 @@ discipline.   When a task of lower priority than the ceiling
 priority successfully obtains the semaphore, its priority is
 raised to the ceiling priority.  When the task holding the task
 completely releases the binary semaphore (i.e. not for a nested
-release), the holder’s priority is restored to the value it had
+release), the holder's priority is restored to the value it had
 before any higher priority was put into effect.
 
 The need to identify the highest priority task which
@@ -298,7 +298,7 @@ initial count.  If a binary semaphore is created with a count of
 zero (0) to indicate that it has been allocated, then the task
 creating the semaphore is considered the current holder of the
 semaphore.  At create time the method for ordering waiting tasks
-in the semaphore’s task wait queue (by FIFO or task priority) is
+in the semaphore's task wait queue (by FIFO or task priority) is
 specified.  Additionally, the priority inheritance or priority
 ceiling algorithm may be selected for local, binary semaphores
 that use the priority task wait queue blocking discipline.  If
@@ -346,9 +346,9 @@ one of the following situations applies:
   wait before returning with an error status code.
 
 If the task waits to acquire the semaphore, then it
-is placed in the semaphore’s task wait queue in either FIFO or
+is placed in the semaphore's task wait queue in either FIFO or
 task priority order.  If the task blocked waiting for a binary
-semaphore using priority inheritance and the task’s priority is
+semaphore using priority inheritance and the task's priority is
 greater than that of the task currently holding the semaphore,
 then the holding task will inherit the priority of the blocking
 task.  All tasks waiting on a semaphore are returned an error
@@ -356,7 +356,7 @@ code when the semaphore is deleted.
 
 When a task successfully obtains a semaphore using
 priority ceiling and the priority ceiling for this semaphore is
-greater than that of the holder, then the holder’s priority will
+greater than that of the holder, then the holder's priority will
 be elevated.
 
 Releasing a Semaphore
@@ -383,17 +383,17 @@ Deleting a Semaphore
 
 The ``rtems_semaphore_delete`` directive removes a semaphore
 from the system and frees its control block.  A semaphore can be
-deleted by any local task that knows the semaphore’s ID.  As a
+deleted by any local task that knows the semaphore's ID.  As a
 result of this directive, all tasks blocked waiting to acquire
 the semaphore will be readied and returned a status code which
 indicates that the semaphore was deleted.  Any subsequent
-references to the semaphore’s name and ID are invalid.
+references to the semaphore's name and ID are invalid.
 
 Directives
 ==========
 
-This section details the semaphore manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the semaphore manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.
 
@@ -489,7 +489,7 @@ defined by RTEMS:
 Semaphores should not be made global unless remote
 tasks must interact with the created semaphore.  This is to
 avoid the system overhead incurred by the creation of a global
-semaphore.  When a global semaphore is created, the semaphore’s
+semaphore.  When a global semaphore is created, the semaphore's
 name and id must be transmitted to every node in the system for
 insertion in the local copy of the global object table.
 
@@ -584,7 +584,7 @@ by RTEMS.
 **NOTES:**
 
 The calling task will be preempted if it is enabled
-by the task’s execution mode and a higher priority local task is
+by the task's execution mode and a higher priority local task is
 waiting on the deleted semaphore.  The calling task will NOT be
 preempted if all of the tasks that are waiting on the semaphore
 are remote tasks.
@@ -643,7 +643,7 @@ semaphore count is zero or negative, then a status code is returned
 indicating that the semaphore is not available. If the calling task
 chooses to wait for a semaphore and the current semaphore count is zero or
 negative, then it is decremented by one and the calling task is placed on
-the semaphore’s wait queue and blocked.  If the semaphore was created with
+the semaphore's wait queue and blocked.  If the semaphore was created with
 the ``RTEMS_PRIORITY`` attribute, then the calling task is
 inserted into the queue according to its priority.  However, if the
 semaphore was created with the ``RTEMS_FIFO`` attribute, then
@@ -713,9 +713,9 @@ SEMAPHORE_RELEASE - Release a semaphore
 
 This directive releases the semaphore specified by
 id.  The semaphore count is incremented by one.  If the count is
-zero or negative, then the first task on this semaphore’s wait
+zero or negative, then the first task on this semaphore's wait
 queue is removed and unblocked.  The unblocked task may preempt
-the running task if the running task’s preemption mode is
+the running task if the running task's preemption mode is
 enabled and the unblocked task has a higher priority than the
 running task.
 
@@ -769,7 +769,7 @@ the semaphore
 **DESCRIPTION:**
 
 This directive unblocks all tasks waiting on the semaphore specified by
-id.  Since there are tasks blocked on the semaphore, the semaphore’s
+id.  Since there are tasks blocked on the semaphore, the semaphore's
 count is not changed by this directive and thus is zero before and
 after this directive is executed.  Tasks which are unblocked as the
 result of this directive will return from the``rtems_semaphore_obtain`` directive with a
@@ -777,7 +777,7 @@ status code of ``RTEMS_UNSATISFIED`` to indicate
 that the semaphore was not obtained.
 
 This directive may unblock any number of tasks.  Any of the unblocked
-tasks may preempt the running task if the running task’s preemption mode is
+tasks may preempt the running task if the running task's preemption mode is
 enabled and an unblocked task has a higher priority than the
 running task.
 
diff --git a/c_user/signal_manager.rst b/c_user/signal_manager.rst
index 2b671b1..b11bf89 100644
--- a/c_user/signal_manager.rst
+++ b/c_user/signal_manager.rst
@@ -24,12 +24,12 @@ Signal Manager Definitions
 
 The signal manager allows a task to optionally define
 an asynchronous signal routine (ASR).  An ASR is to a task what
-an ISR is to an application’s set of tasks.  When the processor
+an ISR is to an application's set of tasks.  When the processor
 is interrupted, the execution of an application is also
 interrupted and an ISR is given control.  Similarly, when a
-signal is sent to a task, that task’s execution path will be
+signal is sent to a task, that task's execution path will be
 "interrupted" by the ASR.  Sending a signal to a task has no
-effect on the receiving task’s current execution state... index:: rtems_signal_set
+effect on the receiving task's current execution state... index:: rtems_signal_set
 
 A signal flag is used by a task (or ISR) to inform
 another task of the occurrence of a significant situation.
@@ -40,7 +40,7 @@ is used to manipulate signal sets.
 
 A signal set is posted when it is directed (or sent) to a
 task. A pending signal is a signal that has been sent to a task
-with a valid ASR, but has not been processed by that task’s ASR.
+with a valid ASR, but has not been processed by that task's ASR.
 
 A Comparison of ASRs and ISRs
 -----------------------------
@@ -85,7 +85,7 @@ Building an ASR Mode
 --------------------
 .. index:: ASR mode, building
 
-In general, an ASR’s mode is built by a bitwise OR of
+In general, an ASR's mode is built by a bitwise OR of
 the desired mode components.  The set of valid mode components
 is the same as those allowed with the task_create and task_mode
 directives.  A complete list of mode options is provided in the
@@ -132,19 +132,19 @@ Establishing an ASR
 
 The ``rtems_signal_catch`` directive establishes an ASR for the
 calling task.  The address of the ASR and its execution mode are
-specified to this directive.  The ASR’s mode is distinct from
-the task’s mode.  For example, the task may allow preemption,
-while that task’s ASR may have preemption disabled.  Until a
+specified to this directive.  The ASR's mode is distinct from
+the task's mode.  For example, the task may allow preemption,
+while that task's ASR may have preemption disabled.  Until a
 task calls ``rtems_signal_catch`` the first time,
 its ASR is invalid, and no signal sets can be sent to the task.
 
 A task may invalidate its ASR and discard all pending
 signals by calling ``rtems_signal_catch``
-with a value of NULL for the ASR’s address.  When a task’s
+with a value of NULL for the ASR's address.  When a task's
 ASR is invalid, new signal sets sent to this task are discarded.
 
 A task may disable ASR processing (``RTEMS_NO_ASR``) via the
-task_mode directive.  When a task’s ASR is disabled, the signals
+task_mode directive.  When a task's ASR is disabled, the signals
 sent to it are left pending to be processed later when the ASR
 is enabled.
 
@@ -153,7 +153,7 @@ be called from an ASR.  A task is only allowed one active ASR.
 Thus, each call to ``rtems_signal_catch``
 replaces the previous one.
 
-Normally, signal processing is disabled for the ASR’s
+Normally, signal processing is disabled for the ASR's
 execution mode, but if signal processing is enabled for the ASR,
 the ASR must be reentrant.
 
@@ -165,7 +165,7 @@ tasks and ISRs to send signals to a target task.  The target task and
 a set of signals are specified to the``rtems_signal_send`` directive.  The sending
 of a signal to a task has no effect on the execution state of
 that task.  If the task is not the currently running task, then
-the signals are left pending and processed by the task’s ASR the
+the signals are left pending and processed by the task's ASR the
 next time the task is dispatched to run.  The ASR is executed
 immediately before the task is dispatched.  If the currently
 running task sends a signal to itself or is sent a signal from
@@ -209,8 +209,8 @@ prior to entering the ASR.
 Directives
 ==========
 
-This section details the signal manager’s directives.
-A subsection is dedicated to each of this manager’s directives
+This section details the signal manager's directives.
+A subsection is dedicated to each of this manager's directives
 and describes the calling sequence, related constants, usage,
 and status codes.
 
@@ -242,7 +242,7 @@ specifies the entry point of the ASR.  If asr_handler is NULL,
 the ASR for the calling task is invalidated and all pending
 signals are cleared.  Any signals sent to a task with an invalid
 ASR are discarded.  The mode parameter specifies the execution
-mode for the ASR.  This execution mode supersedes the task’s
+mode for the ASR.  This execution mode supersedes the task's
 execution mode while the ASR is executing.
 
 **NOTES:**
@@ -308,7 +308,7 @@ time the task is dispatched to run.
 **NOTES:**
 
 Sending a signal set to a task has no effect on that
-task’s state.  If a signal set is sent to a blocked task, then
+task's state.  If a signal set is sent to a blocked task, then
 the task will remain blocked and the signals will be processed
 when the task becomes the running task.
 
diff --git a/c_user/stack_bounds_checker.rst b/c_user/stack_bounds_checker.rst
index 23ddac1..0cf075b 100644
--- a/c_user/stack_bounds_checker.rst
+++ b/c_user/stack_bounds_checker.rst
@@ -36,18 +36,18 @@ Execution
 ---------
 
 The stack bounds checker operates as a set of task extensions.  At
-task creation time, the task’s stack is filled with a pattern to
+task creation time, the task's stack is filled with a pattern to
 indicate the stack is unused.  As the task executes, it will overwrite
-this pattern in memory.  At each task switch, the stack bounds checker’s
+this pattern in memory.  At each task switch, the stack bounds checker's
 task switch extension is executed.  This extension checks that:
 
-- the last ``n`` bytes of the task’s stack have
+- the last ``n`` bytes of the task's stack have
   not been overwritten.  If this pattern has been damaged, it
   indicates that at some point since this task was context
   switch to the CPU, it has used too much stack space.
 
 - the current stack pointer of the task is not within
-  the address range allocated for use as the task’s stack.
+  the address range allocated for use as the task's stack.
 
 If either of these conditions is detected, then a blown stack
 error is reported using the ``printk`` routine.
@@ -131,13 +131,13 @@ The following is an example of the output generated:
     Damaged pattern begins at 0x003e5758 and is 128 bytes long
 
 The above includes the task id and a pointer to the task control block as
-well as enough information so one can look at the task’s stack and
+well as enough information so one can look at the task's stack and
 see what was happening.
 
 Routines
 ========
 
-This section details the stack bounds checker’s routines.
+This section details the stack bounds checker's routines.
 A subsection is dedicated to each of routines
 and describes the calling sequence, related constants, usage,
 and status codes.
diff --git a/c_user/symmetric_multiprocessing_services.rst b/c_user/symmetric_multiprocessing_services.rst
index 5e2e92c..998a066 100644
--- a/c_user/symmetric_multiprocessing_services.rst
+++ b/c_user/symmetric_multiprocessing_services.rst
@@ -173,7 +173,7 @@ clusters.  Clusters with a cardinality of one are partitions.  Each cluster is
 owned by exactly one scheduler instance.
 
 Clustered scheduling helps to control the worst-case latencies in
-multi-processor systems, see *Brandenburg, Björn B.: Scheduling and
+multi-processor systems, see *Brandenburg, Bjorn B.: Scheduling and
 Locking in Multiprocessor Real-Time Operating Systems. PhD thesis, 2011.http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf*.  The goal is to
 reduce the amount of shared state in the system and thus prevention of lock
 contention. Modern multi-processor systems tend to have several layers of data
@@ -220,9 +220,9 @@ appended to the FIFO.  To dequeue a task the highest priority task of the first
 priority queue in the FIFO is selected.  Then the first priority queue is
 removed from the FIFO.  In case the previously first priority queue is not
 empty, then it is appended to the FIFO.  So there is FIFO fairness with respect
-to the highest priority task of each scheduler instances. See also *Brandenburg, Björn B.: A fully preemptive multiprocessor semaphore protocol for
+to the highest priority task of each scheduler instances. See also *Brandenburg, Bjorn B.: A fully preemptive multiprocessor semaphore protocol for
 latency-sensitive real-time applications. In Proceedings of the 25th Euromicro
-Conference on Real-Time Systems (ECRTS 2013), pages 292–302, 2013.http://www.mpi-sws.org/~bbb/papers/pdf/ecrts13b.pdf*.
+Conference on Real-Time Systems (ECRTS 2013), pages 292-302, 2013.http://www.mpi-sws.org/~bbb/papers/pdf/ecrts13b.pdf*.
 
 Such a two level queue may need a considerable amount of memory if fast enqueue
 and dequeue operations are desired (depends on the scheduler instance count).
diff --git a/c_user/task_manager.rst b/c_user/task_manager.rst
index 2ae5372..57c47f4 100644
--- a/c_user/task_manager.rst
+++ b/c_user/task_manager.rst
@@ -30,7 +30,7 @@ by the task manager are:
 
 - ``rtems_task_set_priority`` - Set task priority
 
-- ``rtems_task_mode`` - Change current task’s mode
+- ``rtems_task_mode`` - Change current task's mode
 
 - ``rtems_task_wake_after`` - Wake up after interval
 
@@ -69,7 +69,7 @@ task concept:
 - a sequence of closely related computations which can execute
   concurrently with other computational sequences.
 
-From RTEMS’ perspective, a task is the smallest thread of
+From RTEMS' perspective, a task is the smallest thread of
 execution which can compete on its own for system resources.  A
 task is manifested by the existence of a task control block
 (TCB).
@@ -84,20 +84,20 @@ reserves a TCB for each task configured.  A TCB is allocated
 upon creation of the task and is returned to the TCB free list
 upon deletion of the task.
 
-The TCB’s elements are modified as a result of system calls made
+The TCB's elements are modified as a result of system calls made
 by the application in response to external and internal stimuli.
 TCBs are the only RTEMS internal data structure that can be
 accessed by an application via user extension routines.  The TCB
-contains a task’s name, ID, current priority, current and
+contains a task's name, ID, current priority, current and
 starting states, execution mode, TCB user extension pointer,
 scheduling control structures, as well as data required by a
 blocked task.
 
-A task’s context is stored in the TCB when a task switch occurs.
+A task's context is stored in the TCB when a task switch occurs.
 When the task regains control of the processor, its context is
 restored from the TCB.  When a task is restarted, the initial
 state of the task is restored from the starting context area in
-the task’s TCB.
+the task's TCB.
 
 Task States
 -----------
@@ -131,7 +131,7 @@ Task Priority
 .. index:: priority, task
 .. index:: rtems_task_priority
 
-A task’s priority determines its importance in relation to the
+A task's priority determines its importance in relation to the
 other tasks executing on the same processor.  RTEMS supports 255
 levels of priority ranging from 1 to 255.  The data type``rtems_task_priority`` is used to store task
 priorities.
@@ -158,7 +158,7 @@ Task Mode
 .. index:: task mode
 .. index:: rtems_task_mode
 
-A task’s execution mode is a combination of the following
+A task's execution mode is a combination of the following
 four components:
 
 - preemption
@@ -169,14 +169,14 @@ four components:
 
 - interrupt level
 
-It is used to modify RTEMS’ scheduling process and to alter the
+It is used to modify RTEMS' scheduling process and to alter the
 execution environment of the task.  The data type``rtems_task_mode`` is used to manage the task
 execution mode... index:: preemption
 
 The preemption component allows a task to determine when control of the
 processor is relinquished.  If preemption is disabled
 (``RTEMS_NO_PREEMPT``), the task will retain control of the
-processor as long as it is in the executing state – even if a higher
+processor as long as it is in the executing state - even if a higher
 priority task is made ready.  If preemption is enabled
 (``RTEMS_PREEMPT``)  and a higher priority task is made ready,
 then the processor will be taken away from the current task immediately and
@@ -300,9 +300,9 @@ Per task variables are used to support global variables whose value
 may be unique to a task. After indicating that a variable should be
 treated as private (i.e. per-task) the task can access and modify the
 variable, but the modifications will not appear to other tasks, and
-other tasks’ modifications to that variable will not affect the value
+other tasks' modifications to that variable will not affect the value
 seen by the task.  This is accomplished by saving and restoring the
-variable’s value each time a task switch occurs to or from the calling task.
+variable's value each time a task switch occurs to or from the calling task.
 
 The value seen by other tasks, including those which have not added the
 variable to their set and are thus accessing the variable as a common
@@ -322,14 +322,14 @@ Task variables increase the context switch time to and from the
 tasks that own them so it is desirable to minimize the number of
 task variables.  One efficient method is to have a single task
 variable that is a pointer to a dynamically allocated structure
-containing the task’s private "global" data.
+containing the task's private "global" data.
 
 A critical point with per-task variables is that each task must separately
 request that the same global variable is per-task private.
 
 *WARNING*: Per-Task variables are inherently broken on SMP systems. They
 only work correctly when there is one task executing in the system and
-that task is the logical owner of the value in the per-task variable’s
+that task is the logical owner of the value in the per-task variable's
 location. There is no way for a single memory image to contain the
 correct value for each task executing on each core. Consequently,
 per-task variables are disabled in SMP configurations of RTEMS.
@@ -374,7 +374,7 @@ Building a Mode and Mask
 
 In general, a mode and its corresponding mask is built by a
 bitwise OR of the desired components.  The set of valid mode
-constants and each mode’s corresponding mask constant is
+constants and each mode's corresponding mask constant is
 listed below:
 
 - ``RTEMS_PREEMPT`` is masked by``RTEMS_PREEMPT_MASK`` and enables preemption
@@ -407,7 +407,7 @@ directive to place a task at interrupt level 3 and make it
 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
+RTEMS_NO_PREEMPT_MASK`` to indicate that the calling task's
 interrupt level and preemption mode are being altered.
 
 Operations
@@ -450,20 +450,20 @@ on a task prior to starting it are nullified when the task is
 started.
 
 With the ``rtems_task_start``
-directive the user specifies the task’s
+directive the user specifies the task's
 starting address and argument.  The argument is used to
 communicate some startup information to the task.  As part of
-this directive, RTEMS initializes the task’s stack based upon
-the task’s initial execution mode and start address.  The
+this directive, RTEMS initializes the task's stack based upon
+the task's initial execution mode and start address.  The
 starting argument is passed to the task in accordance with the
-target processor’s calling convention.
+target processor's calling convention.
 
 The ``rtems_task_restart``
 directive restarts a task at its initial
 starting address with its original priority and execution mode,
 but with a possibly different argument.  The new argument may be
 used to distinguish between the original invocation of the task
-and subsequent invocations.  The task’s stack and control block
+and subsequent invocations.  The task's stack and control block
 are modified to reflect their original creation values.
 Although references to resources that have been requested are
 cleared, resources allocated by the task are NOT automatically
@@ -519,9 +519,9 @@ 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
+the new 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
+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,9 +534,9 @@ Changing Task Mode
 
 The ``rtems_task_mode``
 directive is used to obtain or change the current
-execution mode of the calling task.  A task’s execution mode is
+execution mode of the calling task.  A task's execution mode is
 used to enable preemption, timeslicing, ASR processing, and to
-set the task’s interrupt level.
+set the task's interrupt level.
 
 The ``rtems_task_restart``
 directive resets the mode of a task to its
@@ -548,9 +548,9 @@ Task Deletion
 RTEMS provides the ``rtems_task_delete``
 directive to allow a task to
 delete itself or any other task.  This directive removes all
-RTEMS references to the task, frees the task’s control block,
+RTEMS references to the task, frees the task's control block,
 removes it from resource wait queues, and deallocates its stack
-as well as the optional floating point context.  The task’s name
+as well as the optional floating point context.  The 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
@@ -589,8 +589,8 @@ an option for some use cases.
 Directives
 ==========
 
-This section details the task manager’s directives.  A
-subsection is dedicated to each of this manager’s directives and
+This section details the task manager's directives.  A
+subsection is dedicated to each of this manager's directives and
 describes the calling sequence, related constants, usage, and
 status codes.
 
@@ -629,7 +629,7 @@ TASK_CREATE - Create a task
 This directive creates a task which resides on the local node.
 It allocates and initializes a TCB, a stack, and an optional
 floating point context area.  The mode parameter contains values
-which sets the task’s initial execution mode.  The``RTEMS_FLOATING_POINT`` attribute should be
+which sets the task's initial execution mode.  The``RTEMS_FLOATING_POINT`` attribute should be
 specified if the created task
 is to use a numeric coprocessor.  For performance reasons, it is
 recommended that tasks not using the numeric coprocessor should
@@ -713,7 +713,7 @@ target processor in a processor dependent fashion.
 Tasks should not be made global unless remote tasks must
 interact with them.  This avoids the system overhead incurred by
 the creation of a global task.  When a global task is created,
-the task’s name and id must be transmitted to every node in the
+the task's name and id must be transmitted to every node in the
 system for insertion in the local copy of the global object
 table.
 
@@ -820,7 +820,7 @@ TASK_START - Start a task
 
 This directive readies the task, specified by ``id``, for execution
 based on the priority and execution mode specified when the task
-was created.  The starting address of the task is given in``entry_point``.  The task’s starting argument is contained in
+was created.  The starting address of the task is given in``entry_point``.  The task's starting argument is contained in
 argument.  This argument can be a single value or used as an index into an
 array of parameter blocks.  The type of this numeric argument is an unsigned
 integer type with the property that any valid pointer to void can be converted
@@ -861,13 +861,13 @@ TASK_RESTART - Restart a task
 **DESCRIPTION:**
 
 This directive resets the task specified by id to begin
-execution at its original starting address.  The task’s priority
+execution at its original starting address.  The task's priority
 and execution mode are set to the original creation values.  If
 the task is currently blocked, RTEMS automatically makes the
 task ready.  A task can be restarted from any state, except the
 dormant state.
 
-The task’s starting argument is contained in argument.  This argument can be a
+The task's starting argument is contained in argument.  This argument can be a
 single value or an index into an array of parameter blocks.  The type of this
 numeric argument is an unsigned integer type with the property that any valid
 pointer to void can be converted to this type and then converted back to a
@@ -1086,16 +1086,16 @@ TASK_SET_PRIORITY - Set task priority
 This directive manipulates the priority of the task specified by
 id.  An id of ``RTEMS_SELF`` is used to indicate
 the calling task.  When new_priority is not equal to``RTEMS_CURRENT_PRIORITY``, the specified
-task’s previous priority is returned in old_priority.  When
+task's previous priority is returned in old_priority.  When
 new_priority is ``RTEMS_CURRENT_PRIORITY``,
-the specified task’s current
+the specified task's current
 priority is returned in old_priority.  Valid priorities range
 from a high of 1 to a low of 255.
 
 **NOTES:**
 
 The calling task may be preempted if its preemption mode is
-enabled and it lowers its own priority or raises another task’s
+enabled and it lowers its own priority or raises another task's
 priority.
 
 In case the new priority equals the current priority of the task, then nothing
@@ -1107,12 +1107,12 @@ change the priority of the specified task.
 
 If the task specified by id is currently holding any binary
 semaphores which use the priority inheritance algorithm, then
-the task’s priority cannot be lowered immediately.  If the
-task’s priority were lowered immediately, then priority
-inversion results.  The requested lowering of the task’s
+the task's priority cannot be lowered immediately.  If the
+task's priority were lowered immediately, then priority
+inversion results.  The requested lowering of the task's
 priority will occur when the task has released all priority
-inheritance binary semaphores.  The task’s priority can be
-increased regardless of the task’s use of priority inheritance
+inheritance binary semaphores.  The task's priority can be
+increased regardless of the task's use of priority inheritance
 binary semaphores.
 
 TASK_MODE - Change the current task mode
@@ -1144,7 +1144,7 @@ TASK_MODE - Change the current task mode
 **DESCRIPTION:**
 
 This directive manipulates the execution mode of the calling
-task.  A task’s execution mode enables and disables preemption,
+task.  A task's execution mode enables and disables preemption,
 timeslicing, asynchronous signal processing, as well as
 specifying the current interrupt level.  To modify an execution
 mode, the mode class(es) to be changed must be specified in the
@@ -1167,7 +1167,7 @@ To temporarily disable the processing of a valid ASR, a task
 should call this directive with the ``RTEMS_NO_ASR``
 indicator specified in mode.
 
-The set of task mode constants and each mode’s corresponding
+The set of task mode constants and each mode's corresponding
 mask constant is provided in the following table:
 
 - ``RTEMS_PREEMPT`` is masked by``RTEMS_PREEMPT_MASK`` and enables preemption
@@ -1327,12 +1327,12 @@ This directive adds the memory location specified by the
 ptr argument to the context of the given task.  The variable will
 then be private to the task.  The task can access and modify the
 variable, but the modifications will not appear to other tasks, and
-other tasks’ modifications to that variable will not affect the value
+other tasks' modifications to that variable will not affect the value
 seen by the task.  This is accomplished by saving and restoring the
-variable’s value each time a task switch occurs to or from the calling task.
-If the dtor argument is non-NULL it specifies the address of a ‘destructor’
+variable's value each time a task switch occurs to or from the calling task.
+If the dtor argument is non-NULL it specifies the address of a 'destructor'
 function which will be called when the task is deleted.  The argument
-passed to the destructor function is the task’s value of the variable.
+passed to the destructor function is the task's value of the variable.
 
 **NOTES:**
 
@@ -1342,8 +1342,8 @@ Task variables increase the context switch time to and from the
 tasks that own them so it is desirable to minimize the number of
 task variables.  One efficient method
 is to have a single task variable that is a pointer to a dynamically
-allocated structure containing the task’s private ‘global’ data.
-In this case the destructor function could be ‘free’.
+allocated structure containing the task's private 'global' data.
+In this case the destructor function could be 'free'.
 
 Per-task variables are disabled in SMP configurations and this service
 is not available.
@@ -1420,7 +1420,7 @@ TASK_VARIABLE_DELETE - Remove per task variable
 
 **DESCRIPTION:**
 
-This directive removes the given location from a task’s context.
+This directive removes the given location from a task's context.
 
 **NOTES:**
 
diff --git a/c_user/timer_manager.rst b/c_user/timer_manager.rst
index 828cfe2..2d83bf9 100644
--- a/c_user/timer_manager.rst
+++ b/c_user/timer_manager.rst
@@ -183,16 +183,16 @@ Deleting a Timer
 
 The ``rtems_timer_delete`` directive is used to delete a timer.
 If the timer is running and has not expired, the timer is
-automatically canceled.  The timer’s control block is returned
+automatically canceled.  The timer's control block is returned
 to the TMCB free list when it is deleted.  A timer can be
 deleted by a task other than the task which created the timer.
-Any subsequent references to the timer’s name and ID are invalid.
+Any subsequent references to the timer's name and ID are invalid.
 
 Directives
 ==========
 
-This section details the timer manager’s directives.
-A subsection is dedicated to each of this manager’s directives
+This section details the timer manager's directives.
+A subsection is dedicated to each of this manager's directives
 and describes the calling sequence, related constants, usage,
 and status codes.
 
diff --git a/c_user/timespec_helpers.rst b/c_user/timespec_helpers.rst
index f7c9802..f8ef9c4 100644
--- a/c_user/timespec_helpers.rst
+++ b/c_user/timespec_helpers.rst
@@ -9,9 +9,9 @@ instances of the POSIX ``struct timespec`` structure.
 
 The directives provided by the timespec helpers manager are:
 
-- ``rtems_timespec_set`` - Set timespec’s value
+- ``rtems_timespec_set`` - Set timespec's value
 
-- ``rtems_timespec_zero`` - Zero timespec’s value
+- ``rtems_timespec_zero`` - Zero timespec's value
 
 - ``rtems_timespec_is_valid`` - Check if timespec is valid
 
@@ -101,8 +101,8 @@ User can also check validity of timespec with``rtems_timespec_is_valid`` routine
 Directives
 ==========
 
-This section details the Timespec Helpers manager’s directives.
-A subsection is dedicated to each of this manager’s directives
+This section details the Timespec Helpers manager's directives.
+A subsection is dedicated to each of this manager's directives
 and describes the calling sequence, related constants, usage,
 and status codes.
 
diff --git a/c_user/user_extensions.rst b/c_user/user_extensions.rst
index 1108afd..5b3ccb9 100644
--- a/c_user/user_extensions.rst
+++ b/c_user/user_extensions.rst
@@ -72,7 +72,7 @@ following structure:.. index:: rtems_extensions_table
 
 RTEMS allows the user to have multiple extension sets
 active at the same time.  First, a single static extension set
-may be defined as the application’s User Extension Table which
+may be defined as the application's User Extension Table which
 is included as part of the Configuration Table.  This extension
 set is active for the entire life of the system and may not be
 deleted.  This extension set is especially important because it
@@ -112,9 +112,9 @@ TCB Extension Area
 .. index:: TCB extension area
 
 RTEMS provides for a pointer to a user-defined data
-area for each extension set to be linked to each task’s control
+area for each extension set to be linked to each task's control
 block.  This set of pointers is an extension of the TCB and can
-be used to store additional data required by the user’s
+be used to store additional data required by the user's
 extension functions.
 
 The TCB extension is an array of pointers in the TCB. The
@@ -129,7 +129,7 @@ The number of pointers in the area is the same as the number of
 user extension sets configured.  This allows an application to
 augment the TCB with user-defined information.  For example, an
 application could implement task profiling by storing timing
-statistics in the TCB’s extended memory area.  When a task
+statistics in the TCB's extended memory area.  When a task
 context switch is being executed, the TASK_SWITCH extension
 could read a real-time clock to calculate how long the task
 being swapped out has run as well as timestamp the starting time
@@ -144,9 +144,9 @@ be reinitialized by the TASK_RESTART extension and should be
 deallocated by the TASK_DELETE extension when the task is
 deleted.  Since the TCB extension buffers would most likely be
 of a fixed size, the RTEMS partition manager could be used to
-manage the application’s extended memory area.  The application
+manage the application's extended memory area.  The application
 could create a partition of fixed size TCB extension buffers and
-use the partition manager’s allocation and deallocation
+use the partition manager's allocation and deallocation
 directives to obtain and release the extension buffers.
 
 Extensions
@@ -286,7 +286,7 @@ following:.. index:: rtems_task_switch_extension
 where current_task can be used to access the TCB for
 the task that is being swapped out, and heir_task can be used to
 access the TCB for the task being swapped in.  This extension is
-invoked from RTEMS’ dispatcher routine after the current_task
+invoked from RTEMS' dispatcher routine after the current_task
 context has been saved, but before the heir_task context has
 been restored.  This extension should not call any RTEMS
 directives.
@@ -360,8 +360,8 @@ where the_error is the error code passed to the
 fatal_error_occurred directive. This extension is invoked from
 the fatal_error_occurred directive.
 
-If defined, the user’s FATAL error extension is
-invoked before RTEMS’ default fatal error routine is invoked and
+If defined, the user's FATAL error extension is
+invoked before RTEMS' default fatal error routine is invoked and
 the processor is stopped.  For example, this extension could be
 used to pass control to a debugger when a fatal error occurs.
 This extension should not call any RTEMS directives.
@@ -410,7 +410,7 @@ error extension will be the last fatal error extension executed.
 Another example is use of the task delete extension by the
 Standard C Library.  Extension sets which are installed after
 the Standard C Library will operate correctly even if they
-utilize the C Library because the C Library’s TASK_DELETE
+utilize the C Library because the C Library's TASK_DELETE
 extension is invoked after that of the other extensions.
 
 Operations
@@ -444,17 +444,17 @@ Deleting an Extension Set
 -------------------------
 
 The ``rtems_extension_delete`` directive is used to delete an
-extension set.  The extension set’s control block is returned to
+extension set.  The extension set's control block is returned to
 the ESCB free list when it is deleted.  An extension set can be
 deleted by a task other than the task which created the
-extension set.  Any subsequent references to the extension’s
+extension set.  Any subsequent references to the extension's
 name and ID are invalid.
 
 Directives
 ==========
 
-This section details the user extension manager’s
-directives.  A subsection is dedicated to each of this manager’s
+This section details the user extension manager's
+directives.  A subsection is dedicated to each of this manager's
 directives and describes the calling sequence, related
 constants, usage, and status codes.