Convert all Unicode to ASCII(128)

16 files changed, 50 insertions, 50 deletions

diff --git a/bsp_howto/analog.rst b/bsp_howto/analog.rst
index 84b8221..dbccb59 100644
--- a/bsp_howto/analog.rst
+++ b/bsp_howto/analog.rst
@@ -71,7 +71,7 @@ to configure an analog board:
 Initialize an Analog Board
 ==========================
 
-At system initialization, the analog driver’s initialization entry point
+At system initialization, the analog driver's initialization entry point
 will be invoked.  As part of initialization, the driver will perform
 whatever board initialization is required and then set all
 outputs to their configured initial state.
diff --git a/bsp_howto/ata.rst b/bsp_howto/ata.rst
index dbf9f72..6101b4b 100644
--- a/bsp_howto/ata.rst
+++ b/bsp_howto/ata.rst
@@ -101,7 +101,7 @@ following structure:
 
 ATA driver supports separate ATA requests queues for each IDE
 controller (one queue per controller). The following structure contains
-information about controller’s queue and devices attached to the controller:
+information about controller's queue and devices attached to the controller:
 .. code:: c
 
     /*
@@ -153,7 +153,7 @@ implementation supports only two ioctls: BLKIO_REQUEST and
 ATAIO_SET_MULTIPLE_MODE. Each ATA driver ioctl() call generates an
 ATA request which is appended to the appropriate controller queue depending
 on ATA device the request belongs to. If appended request is single request in
-the controller’s queue then ATA driver event is generated.
+the controller's queue then ATA driver event is generated.
 
 ATA driver task which manages queue of ATA driver events is core of ATA
 driver. In current driver version queue of ATA driver events implemented
diff --git a/bsp_howto/clock.rst b/bsp_howto/clock.rst
index d8c454b..870eebf 100644
--- a/bsp_howto/clock.rst
+++ b/bsp_howto/clock.rst
@@ -8,7 +8,7 @@ The purpose of the clock driver is to provide two services for the operating
 system.
 
 - A steady time basis to the kernel, so that the RTEMS primitives that need
-  a clock tick work properly.  See the *Clock Manager* chapter of the*RTEMS Application C User’s Guide* for more details.
+  a clock tick work properly.  See the *Clock Manager* chapter of the*RTEMS Application C User's Guide* for more details.
 
 - An optional time counter to generate timestamps of the uptime and wall
   clock time.
diff --git a/bsp_howto/console.rst b/bsp_howto/console.rst
index 13f7a6c..5436bfb 100644
--- a/bsp_howto/console.rst
+++ b/bsp_howto/console.rst
@@ -36,11 +36,11 @@ and are at http://opengroup.org/onlinepubs/007908775/xsh/termios.h.html.
 
 Having RTEMS support for Termios is beneficial because:
 
-- from the user’s side because it provides standard primitive operations
+- from the user's side because it provides standard primitive operations
   to access the terminal and change configuration settings.  These operations
   are the same under UNIX and RTEMS.
 
-- from the BSP developer’s side because it frees the
+- from the BSP developer's side because it frees the
   developer from dealing with buffer states and mutual exclusions on them.
   Early RTEMS console device drivers also did their own special
   character processing.
diff --git a/bsp_howto/discrete.rst b/bsp_howto/discrete.rst
index c5ce450..c358ee1 100644
--- a/bsp_howto/discrete.rst
+++ b/bsp_howto/discrete.rst
@@ -76,12 +76,12 @@ to configure an discrete I/O board:
 *relay_initial_values*
     is an array of the values that should be written to each output
     word on the board during initialization.  This allows the driver
-    to start with the board’s output  in a known state.
+    to start with the board's output  in a known state.
 
 Initialize a Discrete I/O Board
 ===============================
 
-At system initialization, the discrete I/O driver’s initialization entry point
+At system initialization, the discrete I/O driver's initialization entry point
 will be invoked.  As part of initialization, the driver will perform
 whatever board initializatin is required and then set all
 outputs to their configured initial state.
diff --git a/bsp_howto/index.rst b/bsp_howto/index.rst
index 0f279aa..d422251 100644
--- a/bsp_howto/index.rst
+++ b/bsp_howto/index.rst
@@ -2,7 +2,7 @@
 BSP and Device Driver Development Guide
 =======================================
 
-COPYRIGHT © 1988 - 2015.
+COPYRIGHT (c) 1988 - 2015.
 
 On-Line Applications Research Corporation (OAR).
 
diff --git a/bsp_howto/initilization_code.rst b/bsp_howto/initilization_code.rst
index d6ce46b..4657602 100644
--- a/bsp_howto/initilization_code.rst
+++ b/bsp_howto/initilization_code.rst
@@ -4,7 +4,7 @@ Initialization Code
 Introduction
 ============
 
-The initialization code is the first piece of code executed when there’s a
+The initialization code is the first piece of code executed when there's a
 reset/reboot. Its purpose is to initialize the board for the application.
 This chapter contains a narrative description of the initialization
 process followed by a description of each of the files and routines
@@ -178,7 +178,7 @@ The ``boot_card()`` routine performs the following functions:
   When in the context of the first task but before its body has been
   entered, any C++ Global Constructors will be invoked.
 
-That’s it.  We just went through the entire sequence.
+That's it.  We just went through the entire sequence.
 
 bsp_work_area_initialize() - BSP Specific Work Area Initialization
 ------------------------------------------------------------------
@@ -227,7 +227,7 @@ in the order they appear in the Device Driver Table.
 The Driver Address Table is part of the RTEMS Configuration Table. It
 defines device drivers entry points (initialization, open, close, read,
 write, and control). For more information about this table, please
-refer to the *Configuring a System* chapter in the*RTEMS Application C User’s Guide*.
+refer to the *Configuring a System* chapter in the*RTEMS Application C User's Guide*.
 
 The RTEMS initialization procedure calls the initialization function for
 every driver defined in the RTEMS Configuration Table (this allows
@@ -289,7 +289,7 @@ of ``__uhoh`` in the ``gen68340`` BSP.
 
 At ``__uhoh`` label is the default interrupt handler routine. This
 routine is only called when an unexpected interrupts is raised.  One can
-add their own routine there (in that case there’s a call to a routine -
+add their own routine there (in that case there's a call to a routine -
 $BSP_ROOT/startup/dumpanic.c - that prints which address caused the
 interrupt and the contents of the registers, stack, etc.), but this should
 not return.
@@ -325,7 +325,7 @@ Integrated Processor Registers Initialization
 The CPUs used in many embedded systems are highly complex devices
 with multiple peripherals on the CPU itself.  For these devices,
 there are always some specific integrated processor registers
-that must be initialized.  Refer to the processors’ manuals for
+that must be initialized.  Refer to the processors' manuals for
 details on these registers and be VERY careful programming them.
 
 Data Section Recopy
@@ -348,7 +348,7 @@ The RTEMS Configuration Table
 
 The RTEMS configuration table contains the maximum number of objects RTEMS
 can handle during the application (e.g. maximum number of tasks,
-semaphores, etc.). It’s used to allocate the size for the RTEMS inner data
+semaphores, etc.). It's used to allocate the size for the RTEMS inner data
 structures.
 
 The RTEMS configuration table is application dependent, which means that
@@ -367,7 +367,7 @@ application.  In 4.9 and newer, we have eliminated the BSP copies of the
 configuration tables and are making efforts to make the configuration
 information generated by ``<rtems/confdefs.h>`` constant and read only.
 
-For more information on the RTEMS Configuration Table, refer to the*RTEMS Application C User’s Guide*.
+For more information on the RTEMS Configuration Table, refer to the*RTEMS Application C User's Guide*.
 
 .. COMMENT: COPYRIGHT (c) 1988-2008.
 
diff --git a/bsp_howto/linker_script.rst b/bsp_howto/linker_script.rst
index 684e2db..a9f1c98 100644
--- a/bsp_howto/linker_script.rst
+++ b/bsp_howto/linker_script.rst
@@ -34,7 +34,7 @@ Two types of memories have to be distinguished:
 - ROM - non-volatile but read only
 
 Even though RAM and ROM can be found in every personal computer,
-one generally doesn’t care about them.  In a personal computer,
+one generally doesn't care about them.  In a personal computer,
 a program is nearly always stored on disk and executed in RAM.  Things
 are a bit different for embedded targets: the target will execute the
 program each time it is rebooted or switched on.   The application
@@ -49,7 +49,7 @@ object file format on the Motorola m68k family of microprocessors,
 the following sections will be present:
 
 - *code (``.text``) section*:
-  is the program’s code and it should not be modified.
+  is the program's code and it should not be modified.
   This section may be placed in ROM.
 
 - *non-initialized data (``.bss``) section*:
@@ -57,7 +57,7 @@ the following sections will be present:
 
 - *initialized data (``.data``) section*:
   holds the initialized program data which may be modified during the
-  program’s life.  This means they have to be in RAM.
+  program's life.  This means they have to be in RAM.
   On the other hand, these variables must be set to predefined values, and
   those predefined values have to be stored in ROM.
 
@@ -300,7 +300,7 @@ $BSP340_ROOT/startup/linkcmds.
 Initialized Data
 ================
 
-Now there’s a problem with the initialized data: the ``.data`` section
+Now there's a problem with the initialized data: the ``.data`` section
 has to be in RAM as this data may be modified during the program execution.
 But how will the values be initialized at boot time?
 
@@ -354,7 +354,7 @@ section with an ``awk`` script.  The details of how
 this is done are not relevant.
 
 Step 3 shows the final executable image as it logically appears in
-the target’s non-volatile program memory.  The board initialization
+the target's non-volatile program memory.  The board initialization
 code will copy the ""copy of ``.data`` section" (which are stored in
 ROM) to their reserved location in RAM.
 
diff --git a/bsp_howto/makefiles.rst b/bsp_howto/makefiles.rst
index 528617e..77e7186 100644
--- a/bsp_howto/makefiles.rst
+++ b/bsp_howto/makefiles.rst
@@ -147,10 +147,10 @@ with the toolset, this same information must be used when building the
 application.  So a BSP must include a build configuration file.  The
 configuration file is ``make/custom/BSP.cfg``.
 
-The configuration file is taken into account when building one’s
+The configuration file is taken into account when building one's
 application using the RTEMS template Makefiles (``make/templates``).
 These application template Makefiles have been included with the
-RTEMS source distribution since the early 1990’s.  However there is
+RTEMS source distribution since the early 1990's.  However there is
 a desire in the RTEMS user community to move all provided examples to
 GNU autoconf. They are included in the 4.9 release series and used for
 all examples provided with RTEMS. There is no definite time table for
diff --git a/bsp_howto/miscellanous_support.rst b/bsp_howto/miscellanous_support.rst
index 4c6bb25..735ebd8 100644
--- a/bsp_howto/miscellanous_support.rst
+++ b/bsp_howto/miscellanous_support.rst
@@ -114,7 +114,7 @@ The ``tm27`` test from the RTEMS Timing Test Suite is designed to measure the le
 
 All members of the Timing Test Suite are designed to run *WITHOUT*
 the Clock Device Driver installed.  This increases the predictability
-of the tests’ execution as well as avoids occassionally including the
+of the tests' execution as well as avoids occassionally including the
 overhead of a clock tick interrupt in the time reported.  Because of
 this it is sometimes possible to use the clock tick interrupt source
 as the source of this test interrupt.  On other architectures, it is
diff --git a/bsp_howto/networking.rst b/bsp_howto/networking.rst
index 40ae5b6..123b52c 100644
--- a/bsp_howto/networking.rst
+++ b/bsp_howto/networking.rst
@@ -6,7 +6,7 @@ Introduction
 
 This chapter is intended to provide an introduction to the
 procedure for writing RTEMS network device drivers.
-The example code is taken from the ‘Generic 68360’ network device
+The example code is taken from the 'Generic 68360' network device
 driver.  The source code for this driver is located in the``c/src/lib/libbsp/m68k/gen68360/network`` directory in the RTEMS
 source code distribution.  Having a copy of this driver at
 hand when reading the following notes will help significantly.
@@ -15,7 +15,7 @@ Learn about the network device
 ==============================
 
 Before starting to write the network driver become completely
-familiar with the programmer’s view of the device.
+familiar with the programmer's view of the device.
 The following points list some of the details of the
 device that must be understood before a driver can be written.
 
@@ -70,7 +70,7 @@ data structures and resources.  To ensure the consistency
 of these structures the tasks
 execute only when they hold the network semaphore (``rtems_bsdnet_semaphore``).
 The transmit and receive tasks must abide by this protocol.  Be very
-careful to avoid ‘deadly embraces’ with the other network tasks.
+careful to avoid 'deadly embraces' with the other network tasks.
 A number of routines are provided to make it easier for the network
 driver code to conform to the network task scheduling conventions.
 
@@ -161,9 +161,9 @@ in the device-dependent data structure supplied and maintained by the driver:
 
 ``ifp->if_unit``
     The device number.  The network stack uses this number and the
-    device name for device name lookups.  For example, if``ifp->if_name`` is ‘``scc``’ and ``ifp->if_unit`` is ‘``1``’,
-    the full device name would be ‘``scc1``’.  The unit number should be
-    obtained from the ‘name’ entry in the configuration structure.
+    device name for device name lookups.  For example, if``ifp->if_name`` is '``scc``' and ``ifp->if_unit`` is '``1``',
+    the full device name would be '``scc1``'.  The unit number should be
+    obtained from the 'name' entry in the configuration structure.
 
 ``ifp->if_mtu``
     The maximum transmission unit for the device.  For Ethernet
@@ -212,7 +212,7 @@ Once the attach function  has set up the above entries it must link the
 driver data structure onto the list of devices by
 calling ``if_attach``.  Ethernet devices should then
 call ``ether_ifattach``.  Both functions take a pointer to the
-device’s ``ifnet`` structure as their only argument.
+device's ``ifnet`` structure as their only argument.
 
 The attach function should return a non-zero value to indicate that
 the driver has been successfully configured and attached.
@@ -222,8 +222,8 @@ Write the Driver Start Function.
 
 This function is called each time the network stack wants to start the
 transmitter.  This occures whenever the network stack adds a packet
-to a device’s send queue and the ``IFF_OACTIVE`` bit in the
-device’s ``if_flags`` is not set.
+to a device's send queue and the ``IFF_OACTIVE`` bit in the
+device's ``if_flags`` is not set.
 
 For many devices this function need only set the ``IFF_OACTIVE`` bit in the``if_flags`` and send an event to the transmit task
 indicating that a packet is in the driver transmit queue.
diff --git a/bsp_howto/non_volatile_memory.rst b/bsp_howto/non_volatile_memory.rst
index b85f6ae..1015320 100644
--- a/bsp_howto/non_volatile_memory.rst
+++ b/bsp_howto/non_volatile_memory.rst
@@ -127,7 +127,7 @@ to easily divide the non-volatile memory for different purposes.
 Initialize the Non-Volatile Memory Driver
 =========================================
 
-At system initialization, the non-volatile memory driver’s
+At system initialization, the non-volatile memory driver's
 initialization entry point will be invoked.  As part of
 initialization, the driver will perform
 whatever initializatin is required on each non-volatile memory area.
@@ -140,7 +140,7 @@ the entire device driver.
 Disable Read and Write Handlers
 ===============================
 
-Depending on the target’s non-volatile memory configuration, it may be
+Depending on the target's non-volatile memory configuration, it may be
 possible to write to a status register and make the memory area completely
 inaccessible.  This is target dependent and beyond the standard capabilities
 of any memory type.  The user has the optional capability to provide
diff --git a/bsp_howto/real_time_clock.rst b/bsp_howto/real_time_clock.rst
index c8e0424..7637b9d 100644
--- a/bsp_howto/real_time_clock.rst
+++ b/bsp_howto/real_time_clock.rst
@@ -33,7 +33,7 @@ driver.  There were no DMV177 specific configuration routines.  A BSP
 could use configuration routines to dynamically determine what type
 of real-time clock is on a particular board.  This would be useful for
 a BSP supporting multiple board models.  The relevant ports of
-the DMV177’s ``RTC_Table`` configuration table is below:
+the DMV177's ``RTC_Table`` configuration table is below:
 .. code:: c
 
     #include <bsp.h>
@@ -104,10 +104,10 @@ The ``deviceProbe`` routine returns TRUE if the device
 configured by this entry in the ``RTC_Table`` is present.
 This configuration scheme allows one to support multiple versions
 of the same board with a single BSP.  For example, if the first
-generation of a board had Vendor A’s RTC chip and the second
-generation had Vendor B’s RTC chip, RTC_Table could contain
+generation of a board had Vendor A's RTC chip and the second
+generation had Vendor B's RTC chip, RTC_Table could contain
 information for both.  The ``deviceProbe`` configured
-for Vendor A’s RTC chip would need to return TRUE if the
+for Vendor A's RTC chip would need to return TRUE if the
 board was a first generation one.  The ``deviceProbe``
 routines are very board dependent and must be provided by
 the BSP.
diff --git a/bsp_howto/shared_memory_support.rst b/bsp_howto/shared_memory_support.rst
index 9165de4..93246c6 100644
--- a/bsp_howto/shared_memory_support.rst
+++ b/bsp_howto/shared_memory_support.rst
@@ -11,7 +11,7 @@ This driver is only required in shared memory multiprocessing
 systems that use the RTEMS mulitprocessing support.  For more
 information on RTEMS multiprocessing capabilities and the
 MPCI, refer to the *Multiprocessing Manager* chapter
-of the *RTEMS Application C User’s Guide*.
+of the *RTEMS Application C User's Guide*.
 
 Shared Memory Configuration Table
 =================================
@@ -95,7 +95,7 @@ used from this node.  Most targets will simply return the address
 passed to this routine.  However, some target boards will have a special
 window onto the shared memory.  For example, some VMEbus boards have
 special address windows to access addresses that are normally reserved
-in the CPU’s address space.
+in the CPU's address space.
 .. code:: c
 
     void \*Shm_Convert_address( void \*address )
diff --git a/bsp_howto/target_dependant_files.rst b/bsp_howto/target_dependant_files.rst
index 77a78f1..d154841 100644
--- a/bsp_howto/target_dependant_files.rst
+++ b/bsp_howto/target_dependant_files.rst
@@ -31,10 +31,10 @@ differences between these CPU models which RTEMS must take into account.
 
 The source code found in the ``cpukit/score/cpu`` is required to
 only depend upon the CPU model variations that GCC distinguishes
-for the purposes of multilib’ing.  Multilib is the term the GNU
+for the purposes of multilib'ing.  Multilib is the term the GNU
 community uses to refer to building a single library source multiple
 times with different compiler options so the binary code generated
-is compatible.  As an example, from GCC’s perspective, many PowerPC
+is compatible.  As an example, from GCC's perspective, many PowerPC
 CPU models are just a PPC603e.  Remember that GCC only cares about
 the CPU code itself and need not be aware of any peripherals.  In
 the embedded community, we are exposed to thousands of CPU models
@@ -86,16 +86,16 @@ a particular target board, the following questions should be asked:
 
 - Does a BSP for a similar board exists?
 
-- Is the board’s CPU supported?
+- Is the board's CPU supported?
 
 If there is already a BSP for the board, then things may already be ready
 to start developing application software.  All that remains is to verify
 that the existing BSP provides device drivers for all the peripherals
 on the board that the application will be using.  For example, the application
-in question may require that the board’s Ethernet controller be used and
+in question may require that the board's Ethernet controller be used and
 the existing BSP may not support this.
 
-If the BSP does not exist and the board’s CPU model is supported, then
+If the BSP does not exist and the board's CPU model is supported, then
 examine the reusable chip library and existing BSPs for a close match.
 Other BSPs and libchip provide starting points for the development
 of a new BSP.  It is often possible to copy existing components in
@@ -103,7 +103,7 @@ the reusable chip library or device drivers from BSPs from different
 CPU families as the starting point for a new device driver.
 This will help reduce the development effort required.
 
-If the board’s CPU family is supported but the particular CPU model on
+If the board's CPU family is supported but the particular CPU model on
 that board is not, then the RTEMS port to that CPU family will have to
 be augmented.  After this is done, development of the new BSP can proceed.
 
@@ -179,7 +179,7 @@ describes the commonly found subdirectories under each BSP.
   UARTs (i.e. serial devices).
 
 - *clock*:
-  support for the clock tick – a regular time basis to the kernel.
+  support for the clock tick - a regular time basis to the kernel.
 
 - *timer*:
   support of timer devices.
diff --git a/bsp_howto/timer.rst b/bsp_howto/timer.rst
index 46bdf0c..88a4589 100644
--- a/bsp_howto/timer.rst
+++ b/bsp_howto/timer.rst
@@ -83,11 +83,11 @@ gen68340 UART FIFO Full Mode
 The gen68340 BSP is an example of the use of the timer to support the UART
 input FIFO full mode (FIFO means First In First Out and roughly means
 buffer). This mode consists in the UART raising an interrupt when n
-characters have been received (*n* is the UART’s FIFO length). It results
+characters have been received (*n* is the UART's FIFO length). It results
 in a lower interrupt processing time, but the problem is that a scanf
 primitive will block on a receipt of less than *n* characters. The solution
 is to set a timer that will check whether there are some characters
-waiting in the UART’s input FIFO. The delay time has to be set carefully
+waiting in the UART's input FIFO. The delay time has to be set carefully
 otherwise high rates will be broken:
 
 - if no character was received last time the interrupt subroutine was