From d389819eea3a84e388935153e3be847342809da3 Mon Sep 17 00:00:00 2001 From: Amar Takhar Date: Mon, 18 Jan 2016 00:37:40 -0500 Subject: Convert all Unicode to ASCII(128) --- bsp_howto/analog.rst | 2 +- bsp_howto/ata.rst | 4 ++-- bsp_howto/clock.rst | 2 +- bsp_howto/console.rst | 4 ++-- bsp_howto/discrete.rst | 4 ++-- bsp_howto/index.rst | 2 +- bsp_howto/initilization_code.rst | 14 +++++++------- bsp_howto/linker_script.rst | 10 +++++----- bsp_howto/makefiles.rst | 4 ++-- bsp_howto/miscellanous_support.rst | 2 +- bsp_howto/networking.rst | 18 +++++++++--------- bsp_howto/non_volatile_memory.rst | 4 ++-- bsp_howto/real_time_clock.rst | 8 ++++---- bsp_howto/shared_memory_support.rst | 4 ++-- bsp_howto/target_dependant_files.rst | 14 +++++++------- bsp_howto/timer.rst | 4 ++-- 16 files changed, 50 insertions(+), 50 deletions(-) (limited to 'bsp_howto') 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 ```` 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 @@ -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 -- cgit v1.2.3