rtems/rtems-docs
1
0
Fork 0
mirror of https://git.rtems.org/rtems-docs/ synced 2025-05-14 05:09:33 +08:00
Code Issues Packages Projects Releases Wiki Activity

Convert all Unicode to ASCII(128)

Browse Source
This commit is contained in:
Amar Takhar 2016-01-18 00:37:40 -05:00 committed by Amar Takhar
parent 11e1a6f969
commit d389819eea
121 changed files with 705 additions and 705 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
bsp_howto/analog.rst
View File

@ -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.

4
bsp_howto/ata.rst
View File

@ -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

2
bsp_howto/clock.rst
View File

@ -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.

4
bsp_howto/console.rst
View File

@ -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.

4
bsp_howto/discrete.rst
View File

@ -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.

2
bsp_howto/index.rst
View File

@ -2,7 +2,7 @@
BSP and Device Driver Development Guide
=======================================
COPYRIGHT © 1988 - 2015.
COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).

14
bsp_howto/initilization_code.rst
View File

@ -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.

10
bsp_howto/linker_script.rst
View File

@ -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.

4
bsp_howto/makefiles.rst
View File

@ -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

2
bsp_howto/miscellanous_support.rst
View File

@ -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

18
bsp_howto/networking.rst
View File

@ -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.

4
bsp_howto/non_volatile_memory.rst
View File

@ -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

8
bsp_howto/real_time_clock.rst
View File

@ -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.

4
bsp_howto/shared_memory_support.rst
View File

@ -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 )

14
bsp_howto/target_dependant_files.rst
View File

@ -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.

4
bsp_howto/timer.rst
View File

@ -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

18
c_user/barrier_manager.rst
View File

@ -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:**

18
c_user/board_support_packages.rst
View File

@ -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.

10
c_user/chains.rst
View File

@ -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

12
c_user/clock_manager.rst
View File

@ -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.

28
c_user/configuring_a_system.rst
View File

@ -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:**

14
c_user/constant_bandwidth_server.rst
View File

@ -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.

6
c_user/cpu_usage_statistics.rst
View File

@ -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.

4
c_user/dual_ports_memory_manager.rst
View File

@ -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.

10
c_user/event_manager.rst
View File

@ -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

8
c_user/fatal_error.rst
View File

@ -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:**

16
c_user/glossary.rst
View File

@ -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`

4
c_user/index.rst
View File

@ -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).

6
c_user/initialization.rst
View File

@ -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.

22
c_user/interrupt_manager.rst
View File

@ -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:**

16
c_user/io_manager.rst
View File

@ -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.

22
c_user/key_concepts.rst
View File

@ -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:

36
c_user/message_manager.rst
View File

@ -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.

14
c_user/multiprocessing.rst
View File

@ -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.

8
c_user/overview.rst
View File

@ -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.

12
c_user/partition_manager.rst
View File

@ -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.

4
c_user/pci_library.rst
View File

@ -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.

6
c_user/preface.rst
View File

@ -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.

28
c_user/rate_monotonic_manager.rst
View File

@ -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

20
c_user/red_black_trees.rst
View File

@ -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
--------

20
c_user/region_manager.rst
View File

@ -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
------------------------------------------------

4
c_user/rtems_data_types.rst
View File

@ -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

20
c_user/scheduling_concepts.rst
View File

@ -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.

34
c_user/semaphore_manager.rst
View File

@ -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.

32
c_user/signal_manager.rst
View File

@ -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.

12
c_user/stack_bounds_checker.rst
View File

@ -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.

6
c_user/symmetric_multiprocessing_services.rst
View File

@ -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).

102
c_user/task_manager.rst
View File

@ -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:**

8
c_user/timer_manager.rst
View File

@ -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.

8
c_user/timespec_helpers.rst
View File

@ -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.

28
c_user/user_extensions.rst
View File

@ -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.

4
cpu_supplement/atmel_avr.rst
View File

@ -51,7 +51,7 @@ Register Usage
--------------
A called function may clobber all registers, except RETS, R4-R7, P3-P5,
FP and SP. It may also modify the first 12 bytes in the caller’s stack
FP and SP. It may also modify the first 12 bytes in the caller's stack
frame which is used as an argument area for the first three arguments
(which are passed in R0...R3 but may be placed on the stack by the
called function).
@ -80,7 +80,7 @@ protection mechanisms are not used.
Interrupt Processing
====================
Discussed in this chapter are the AVR’s interrupt response and
Discussed in this chapter are the AVR's interrupt response and
control mechanisms as they pertain to RTEMS.
Vectoring of an Interrupt Handler

4
cpu_supplement/blackfin.rst
View File

@ -55,7 +55,7 @@ Register Usage
--------------
A called function may clobber all registers, except RETS, R4-R7, P3-P5,
FP and SP. It may also modify the first 12 bytes in the caller’s stack
FP and SP. It may also modify the first 12 bytes in the caller's stack
frame which is used as an argument area for the first three arguments
(which are passed in R0...R3 but may be placed on the stack by the
called function).
@ -84,7 +84,7 @@ protection mechanisms are not used.
Interrupt Processing
====================
Discussed in this chapter are the Blackfin’s interrupt response and
Discussed in this chapter are the Blackfin's interrupt response and
control mechanisms as they pertain to RTEMS. The Blackfin architecture
support 16 kinds of interrupts broken down into Core and general-purpose
interrupts.

2
cpu_supplement/index.rst
View File

@ -2,7 +2,7 @@
RTEMS CPU Architecture Supplement
=================================
COPYRIGHT © 1988 - 2015.
COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).

20
cpu_supplement/intel_amd_x86.rst
View File

@ -9,14 +9,14 @@ than being designed for growth.
For information on the i386 processor, refer to the
following documents:
- *386 Programmer’s Reference Manual, Intel, Order No. 230985-002*.
- *386 Programmer's Reference Manual, Intel, Order No. 230985-002*.
- *386 Microprocessor Hardware Reference Manual, Intel,
Order No. 231732-003*.
- *80386 System Software Writer’s Guide, Intel, Order No. 231499-001*.
- *80386 System Software Writer's Guide, Intel, Order No. 231499-001*.
- *80387 Programmer’s Reference Manual, Intel, Order No. 231917-001*.
- *80387 Programmer's Reference Manual, Intel, Order No. 231917-001*.
CPU Model Dependent Features
============================
@ -33,7 +33,7 @@ The macro ``I386_HAS_BSWAP`` is set to 1 to indicate that
this CPU model has the ``bswap`` instruction which
endian swaps a thirty-two bit quantity. This instruction
appears to be present in all CPU models
i486’s and above.
i486's and above.
Calling Conventions
===================
@ -128,8 +128,8 @@ Interrupt Processing
Although RTEMS hides many of the processor
dependent details of interrupt processing, it is important to
understand how the RTEMS interrupt manager is mapped onto the
processor’s unique architecture. Discussed in this chapter are
the the processor’s response and control mechanisms as they
processor's unique architecture. Discussed in this chapter are
the the processor's response and control mechanisms as they
pertain to RTEMS.
Vectoring of Interrupt Handler
@ -175,7 +175,7 @@ Interrupt Levels
----------------
Although RTEMS supports 256 interrupt levels, the
i386 only supports two – enabled and disabled. Interrupts are
i386 only supports two - enabled and disabled. Interrupts are
enabled when the interrupt-enable flag (IF) in the extended
flags (EFLAGS) is set. Conversely, interrupt processing is
inhibited when the IF is cleared. During a non-maskable
@ -225,7 +225,7 @@ System Reset
An RTEMS based application is initiated when the i386 processor is reset.
When the i386 is reset,
- The EAX register is set to indicate the results of the processor’s
- The EAX register is set to indicate the results of the processor's
power-up self test. If the self-test was not executed, the contents of
this register are undefined. Otherwise, a non-zero value indicates the
processor is faulty and a zero value indicates a successful self-test.
@ -253,7 +253,7 @@ When the i386 is reset,
lines are lowered and the processor begins executing in the first megabyte
of memory.
Typically, an intersegment JMP to the application’s initialization code is
Typically, an intersegment JMP to the application's initialization code is
placed at address 0xFFFFFFF0.
Processor Initialization
@ -306,7 +306,7 @@ which is executed before the call to initialize_executive has the following
requirements:
For more information regarding the i386 data structures and their
contents, refer to Intel’s 386 Programmer’s Reference Manual.
contents, refer to Intel's 386 Programmer's Reference Manual.
.. COMMENT: COPYRIGHT (c) 1988-2002.

6
cpu_supplement/lattice_micro32.rst
View File

@ -5,7 +5,7 @@ This chaper discusses the Lattice Mico32 architecture dependencies in
this port of RTEMS. The Lattice Mico32 is a 32-bit Harvard, RISC
architecture "soft" microprocessor, available for free with an open IP
core licensing agreement. Although mainly targeted for Lattice FPGA
devices the microprocessor can be implemented on other vendors’ FPGAs,
devices the microprocessor can be implemented on other vendors' FPGAs,
too.
**Architecture Documents**
@ -192,7 +192,7 @@ handlers are configured or all of them return without taking action to
shutdown the processor or reset, a default fatal error handler is invoked.
Most of the action performed as part of processing the fatal error are
described in detail in the Fatal Error Manager chapter in the User’s
described in detail in the Fatal Error Manager chapter in the User's
Guide. However, the if no user provided extension or BSP specific fatal
error handler takes action, the final default action is to invoke a
CPU architecture specific function. Typically this function disables
@ -221,7 +221,7 @@ In each of the architecture specific chapters, this section will present
a discussion of architecture specific BSP issues. For more information
on developing a BSP, refer to BSP and Device Driver Development Guide
and the chapter titled Board Support Packages in the RTEMS
Applications User’s Guide.
Applications User's Guide.
System Reset
------------

16
cpu_supplement/m68xxx_and_coldfire.rst
View File

@ -17,9 +17,9 @@ For information on the MC68xxx and Coldfire architecture, refer to the following
- *M68000 Family Reference, Motorola, FR68K/D*.
- *MC68020 User’s Manual, Motorola, MC68020UM/AD*.
- *MC68020 User's Manual, Motorola, MC68020UM/AD*.
- *MC68881/MC68882 Floating-Point Coprocessor User’s Manual,
- *MC68881/MC68882 Floating-Point Coprocessor User's Manual,
Motorola, MC68881UM/AD*.
CPU Model Dependent Features
@ -136,7 +136,7 @@ segmentation on any of the MC68xxx family members.
Interrupt Processing
====================
Discussed in this section are the MC68xxx’s interrupt response and
Discussed in this section are the MC68xxx's interrupt response and
control mechanisms as they pertain to RTEMS.
Vectoring of an Interrupt Handler
@ -182,7 +182,7 @@ interrupt stacks automatically perform the following actions:
installed with the interrupt_catch directive, then the RTEMS
interrupt handler will begin execution. The RTEMS interrupt
handler saves all registers which are not preserved according to
the calling conventions and invokes the application’s ISR.
the calling conventions and invokes the application's ISR.
A nested interrupt is processed similarly by these
CPU models with the exception that only a single ISF is placed
@ -339,11 +339,11 @@ the following actions:
Processor Initialization
------------------------
The address of the application’s initialization code should be stored in
The address of the application's initialization code should be stored in
the first vector of the EVT which will allow the immediate vectoring to
the application code. If the application requires that the VBR be some
value besides zero, then it should be set to the required value at this
point. All tasks share the same MC68020’s VBR value. Because interrupts
point. All tasks share the same MC68020's VBR value. Because interrupts
are enabled automatically by RTEMS as part of the context switch to the
first task, the VBR MUST be set by either RTEMS of the BSP before this
occurs ensure correct interrupt vectoring. If processor caching is
@ -351,7 +351,7 @@ to be utilized, then it should be enabled during the reset application
initialization code.
In addition to the requirements described in the
Board Support Packages chapter of the Applications User’s
Board Support Packages chapter of the Applications User's
Manual for the reset code which is executed before the call to
initialize executive, the MC68020 version has the following
specific requirements:
@ -366,7 +366,7 @@ specific requirements:
minimum stack size of MINIMUM_STACK_SIZE bytes is provided for
the initialize executive directive.
- Must initialize the MC68020’s vector table.
- Must initialize the MC68020's vector table.
.. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved.

4
cpu_supplement/mips.rst
View File

@ -74,8 +74,8 @@ Interrupt Processing
Although RTEMS hides many of the processor dependent
details of interrupt processing, it is important to understand
how the RTEMS interrupt manager is mapped onto the processor’s
unique architecture. Discussed in this chapter are the MIPS’s
how the RTEMS interrupt manager is mapped onto the processor's
unique architecture. Discussed in this chapter are the MIPS's
interrupt response and control mechanisms as they pertain to
RTEMS.

16
cpu_supplement/port.rst
View File

@ -42,7 +42,7 @@ unit or coprocessor. When defining the list of features present on a
particular CPU model, one simply notes that floating point hardware
is or is not present and defines a single constant appropriately.
Conditional compilation is utilized to include the appropriate source
code for this CPU model’s feature set. It is important to note that
code for this CPU model's feature set. It is important to note that
this means that RTEMS is thus compiled using the appropriate feature set
and compilation flags optimal for this CPU model used. The alternative
would be to generate a binary which would execute on all family members
@ -118,7 +118,7 @@ Calling Conventions
===================
Each high-level language compiler generates subroutine entry and exit
code based upon a set of rules known as the compiler’s calling convention.
code based upon a set of rules known as the compiler's calling convention.
These rules address the following issues:
- register preservation and usage
@ -127,7 +127,7 @@ These rules address the following issues:
- call and return mechanism
A compiler’s calling convention is of importance when
A compiler's calling convention is of importance when
interfacing to subroutines written in another language either
assembly or high-level. Even when the high-level language and
target processor are the same, different compilers may use
@ -177,7 +177,7 @@ Memory Model
A processor may support any combination of memory
models ranging from pure physical addressing to complex demand
paged virtual memory systems. RTEMS supports a flat memory
model which ranges contiguously over the processor’s allowable
model which ranges contiguously over the processor's allowable
address space. RTEMS does not support segmentation or virtual
memory of any kind. The appropriate memory model for RTEMS
provided by the targeted processor and related characteristics
@ -219,7 +219,7 @@ processors require that an interrupt handler utilize some special control
mechanisms to return to the normal processing stream. Although RTEMS
hides many of the processor dependent details of interrupt processing,
it is important to understand how the RTEMS interrupt manager is mapped
onto the processor’s unique architecture.
onto the processor's unique architecture.
RTEMS supports a dedicated interrupt stack for all architectures.
On architectures with hardware support for a dedicated interrupt stack,
@ -243,7 +243,7 @@ to switch to the interrupt stack.
In some configurations, RTEMS allocates the interrupt stack from the
Workspace Area. The amount of memory allocated for the interrupt stack
is user configured and based upon the ``confdefs.h`` parameter``CONFIGURE_INTERRUPT_STACK_SIZE``. This parameter is described
in detail in the Configuring a System chapter of the User’s Guide.
in detail in the Configuring a System chapter of the User's Guide.
On configurations in which RTEMS allocates the interrupt stack, during
the initialization process, RTEMS will also install its interrupt stack.
In other configurations, the interrupt stack is allocated and installed
@ -318,7 +318,7 @@ handlers are configured or all of them return without taking action to
shutdown the processor or reset, a default fatal error handler is invoked.
Most of the action performed as part of processing the fatal error are
described in detail in the Fatal Error Manager chapter in the User’s
described in detail in the Fatal Error Manager chapter in the User's
Guide. However, the if no user provided extension or BSP specific fatal
error handler takes action, the final default action is to invoke a
CPU architecture specific function. Typically this function disables
@ -414,7 +414,7 @@ In each of the architecture specific chapters, this section will present
a discussion of architecture specific BSP issues. For more information
on developing a BSP, refer to BSP and Device Driver Development Guide
and the chapter titled Board Support Packages in the RTEMS
Applications User’s Guide.
Applications User's Guide.
System Reset
------------

30
cpu_supplement/powerpc.rst
View File

@ -20,27 +20,27 @@ the following documents available from Motorola and IBM:
- *PowerPC Microprocessor Family: The Programming Environment*
(Motorola Document MPRPPCFPE-01).
- *IBM PPC403GB Embedded Controller User’s Manual*.
- *IBM PPC403GB Embedded Controller User's Manual*.
- *PoweRisControl MPC500 Family RCPU RISC Central Processing
Unit Reference Manual* (Motorola Document RCPUURM/AD).
- *PowerPC 601 RISC Microprocessor User’s Manual*
- *PowerPC 601 RISC Microprocessor User's Manual*
(Motorola Document MPR601UM/AD).
- *PowerPC 603 RISC Microprocessor User’s Manual*
- *PowerPC 603 RISC Microprocessor User's Manual*
(Motorola Document MPR603UM/AD).
- *PowerPC 603e RISC Microprocessor User’s Manual*
- *PowerPC 603e RISC Microprocessor User's Manual*
(Motorola Document MPR603EUM/AD).
- *PowerPC 604 RISC Microprocessor User’s Manual*
- *PowerPC 604 RISC Microprocessor User's Manual*
(Motorola Document MPR604UM/AD).
- *PowerPC MPC821 Portable Systems Microprocessor User’s Manual*
- *PowerPC MPC821 Portable Systems Microprocessor User's Manual*
(Motorola Document MPC821UM/AD).
- *PowerQUICC MPC860 User’s Manual* (Motorola Document MPC860UM/AD).
- *PowerQUICC MPC860 User's Manual* (Motorola Document MPC860UM/AD).
Motorola maintains an on-line electronic library for the PowerPC
at the following URL:
@ -75,7 +75,7 @@ model specified on the compilation command line.
Alignment
---------
The macro PPC_ALIGNMENT is set to the PowerPC model’s worst case alignment
The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment
requirement for data types on a byte boundary. This value is used
to derive the alignment restrictions for memory allocated from
regions and partitions.
@ -411,8 +411,8 @@ Interrupt Processing
Although RTEMS hides many of the processor dependent
details of interrupt processing, it is important to understand
how the RTEMS interrupt manager is mapped onto the processor’s
unique architecture. Discussed in this chapter are the PowerPC’s
how the RTEMS interrupt manager is mapped onto the processor's
unique architecture. Discussed in this chapter are the PowerPC's
interrupt response and control mechanisms as they pertain to
RTEMS.
@ -468,10 +468,10 @@ interrupt handler, then upon receipt of the interrupt, the
processor passes control to the RTEMS interrupt handler which
performs the following actions:
- saves the state of the interrupted task on it’s stack,
- saves the state of the interrupted task on it's stack,
- saves all registers which are not normally preserved
by the calling sequence so the user’s interrupt service
by the calling sequence so the user's interrupt service
routine can be written in a high-level language.
- if this is the outermost (i.e. non-nested) interrupt,
@ -560,7 +560,7 @@ An RTEMS based application is initiated or
re-initiated when the PowerPC processor is reset. The PowerPC
architecture defines a Reset Exception, but leaves the
details of the CPU state as implementation specific. Please
refer to the User’s Manual for the CPU model in question.
refer to the User's Manual for the CPU model in question.
In general, at power-up the PowerPC begin execution at address
0xFFF00100 in supervisor mode with all exceptions disabled. For
@ -579,7 +579,7 @@ observed to prevent some emulators from working properly, so it
may be necessary to run with caching disabled to use these emulators.
In addition to the requirements described in the*Board Support Packages* chapter of the RTEMS C
Applications User’s Manual for the reset code
Applications User's Manual for the reset code
which is executed before the call to ``rtems_initialize_executive``,
the PowrePC version has the following specific requirements:
@ -596,7 +596,7 @@ the PowrePC version has the following specific requirements:
- Must enable traps so window overflow and underflow
conditions can be properly handled.
- Must initialize the PowerPC’s initial Exception Table with default
- Must initialize the PowerPC's initial Exception Table with default
handlers.
.. COMMENT: COPYRIGHT (c) 1988-2002.

38
cpu_supplement/sparc.rst
View File

@ -33,7 +33,7 @@ the following documents available from SPARC International, Inc.
**ERC32 Specific Information**
The European Space Agency’s ERC32 is a three chip
The European Space Agency's ERC32 is a three chip
computing core implementing a SPARC V7 processor and associated
support circuitry for embedded space applications. The integer
and floating-point units (90C601E & 90C602E) are based on the
@ -56,7 +56,7 @@ browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32.
- MEC Device Specification
Additionally, the SPARC RISC User’s Guide from Matra
Additionally, the SPARC RISC User's Guide from Matra
MHS documents the functionality of the integer and floating
point units including the instruction set information. To
obtain this document as well as ERC32 components and VHDL models
@ -112,7 +112,7 @@ features present on a particular CPU model, one simply notes
that floating point hardware is or is not present and defines a
single constant appropriately. Conditional compilation is
utilized to include the appropriate source code for this CPU
model’s feature set. It is important to note that this means
model's feature set. It is important to note that this means
that RTEMS is thus compiled using the appropriate feature set
and compilation flags optimal for this CPU model used. The
alternative would be to generate a binary which would execute on
@ -130,7 +130,7 @@ CPU Model Name
The macro CPU_MODEL_NAME is a string which designates
the name of this CPU model. For example, for the European Space
Agency’s ERC32 SPARC model, this macro is set to the string
Agency's ERC32 SPARC model, this macro is set to the string
"erc32".
Floating Point Unit
@ -385,7 +385,7 @@ registers windows.
Because the set of register windows is finite, it is
possible to execute enough save instructions without
corresponding restore’s to consume all of the register windows.
corresponding restore's to consume all of the register windows.
This is easily accomplished in a high level language because
each subroutine typically performs a save instruction upon
entry. Thus having a subroutine call depth greater than the
@ -396,7 +396,7 @@ is responsible for saving the contents of the oldest register
window on the program stack.
Similarly, the subroutines will eventually complete
and begin to perform restore’s. If the restore results in the
and begin to perform restore's. If the restore results in the
need for a register window which has previously been written to
memory as part of an overflow, then a window underflow condition
results. Just like the window overflow, the window underflow
@ -458,7 +458,7 @@ Call and Return Mechanism
The SPARC architecture supports a simple yet
effective call and return mechanism. A subroutine is invoked
via the call (call) instruction. This instruction places the
return address in the caller’s output register 7 (o7). After
return address in the caller's output register 7 (o7). After
the callee executes a save instruction, this value is available
in input register 7 (i7) until the corresponding restore
instruction is executed.
@ -466,7 +466,7 @@ instruction is executed.
The callee returns to the caller via a jmp to the
return address. There is a delay slot following this
instruction which is commonly used to execute a restore
instruction – if a register window was allocated by this
instruction - if a register window was allocated by this
subroutine.
It is important to note that the SPARC subroutine
@ -500,7 +500,7 @@ Parameter Passing
-----------------
RTEMS assumes that arguments are placed in the
caller’s output registers with the first argument in output
caller's output registers with the first argument in output
register 0 (o0), the second argument in output register 1 (o1),
and so forth. Until the callee executes a save instruction, the
parameters are still visible in the output registers. After the
@ -534,7 +534,7 @@ Memory Model
A processor may support any combination of memory
models ranging from pure physical addressing to complex demand
paged virtual memory systems. RTEMS supports a flat memory
model which ranges contiguously over the processor’s allowable
model which ranges contiguously over the processor's allowable
address space. RTEMS does not support segmentation or virtual
memory of any kind. The appropriate memory model for RTEMS
provided by the targeted processor and related characteristics
@ -601,8 +601,8 @@ Most processors require that an interrupt handler utilize some
special control mechanisms to return to the normal processing
stream. Although RTEMS hides many of the processor dependent
details of interrupt processing, it is important to understand
how the RTEMS interrupt manager is mapped onto the processor’s
unique architecture. Discussed in this chapter are the SPARC’s
how the RTEMS interrupt manager is mapped onto the processor's
unique architecture. Discussed in this chapter are the SPARC's
interrupt response and control mechanisms as they pertain to
RTEMS.
@ -676,7 +676,7 @@ interrupt handler, then upon receipt of the interrupt, the
processor passes control to the RTEMS interrupt handler which
performs the following actions:
- saves the state of the interrupted task on it’s stack,
- saves the state of the interrupted task on it's stack,
- insures that a register window is available for
subsequent traps,
@ -713,7 +713,7 @@ trap cannot be correctly processed unless (1) traps are enabled
and (2) a register window is reserved for traps. Thus, the
RTEMS interrupt handler insures that a register window is
available for subsequent traps before enabling traps and
invoking the user’s interrupt handler.
invoking the user's interrupt handler.
Interrupt Levels
----------------
@ -792,7 +792,7 @@ execute on the stack of the RTEMS task which they interrupted.
This artificially inflates the stack requirements for each task
since EVERY task stack would have to include enough space to
account for the worst case interrupt stack requirements in
addition to it’s own worst case usage. RTEMS addresses this
addition to it's own worst case usage. RTEMS addresses this
problem on the SPARC by providing a dedicated interrupt stack
managed by software.
@ -864,7 +864,7 @@ to support a particular processor and target board combination.
This chapter presents a discussion of SPARC specific BSP issues.
For more information on developing a BSP, refer to the chapter
titled Board Support Packages in the RTEMS
Applications User’s Guide.
Applications User's Guide.
System Reset
------------
@ -891,14 +891,14 @@ reflect the last trap which occurred before the reset.
Processor Initialization
------------------------
It is the responsibility of the application’s
It is the responsibility of the application's
initialization code to initialize the TBR and install trap
handlers for at least the register window overflow and register
window underflow conditions. Traps should be enabled before
invoking any subroutines to allow for register window
management. However, interrupts should be disabled by setting
the Processor Interrupt Level (pil) field of the psr to 15.
RTEMS installs it’s own Trap Table as part of initialization
RTEMS installs it's own Trap Table as part of initialization
which is initialized with the contents of the Trap Table in
place when the ``rtems_initialize_executive`` directive was invoked.
Upon completion of executive initialization, interrupts are
@ -926,7 +926,7 @@ specific requirements:
- Must enable traps so window overflow and underflow
conditions can be properly handled.
- Must initialize the SPARC’s initial trap table with at
- Must initialize the SPARC's initial trap table with at
least trap handlers for register window overflow and register
window underflow.

28
cpu_supplement/sparc64.rst
View File

@ -16,7 +16,7 @@ through UltraSPARC IV processors.
The following documents were used in developing the SPARC-64 sun4u port:
- UltraSPARC User’s Manual
- UltraSPARC User's Manual
(http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf)
- UltraSPARC IIIi Processor (datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf)
@ -104,7 +104,7 @@ Calling Conventions
Each high-level language compiler generates
subroutine entry and exit code based upon a set of rules known
as the compiler’s calling convention. These rules address the
as the compiler's calling convention. These rules address the
following issues:
- register preservation and usage
@ -113,7 +113,7 @@ following issues:
- call and return mechanism
A compiler’s calling convention is of importance when
A compiler's calling convention is of importance when
interfacing to subroutines written in another language either
assembly or high-level. Even when the high-level language and
target processor are the same, different compilers may use
@ -222,7 +222,7 @@ The SPARC architecture includes a number of special registers:
*``Processor State Register (pstate)``*
The privileged pstate register contains control fields for the proces-
sor’s current state. Its flag fields include the interrupt enable, privi-
sor's current state. Its flag fields include the interrupt enable, privi-
leged mode, and enable FPU.
*``Processor Interrupt Level (pil)``*
@ -270,7 +270,7 @@ registers are shared between adjacent registers windows.
Because the set of register windows is finite, it is
possible to execute enough save instructions without
corresponding restore’s to consume all of the register windows.
corresponding restore's to consume all of the register windows.
This is easily accomplished in a high level language because
each subroutine typically performs a save instruction upon
entry. Thus having a subroutine call depth greater than the
@ -281,7 +281,7 @@ is responsible for saving the contents of the oldest register
window on the program stack.
Similarly, the subroutines will eventually complete
and begin to perform restore’s. If the restore results in the
and begin to perform restore's. If the restore results in the
need for a register window which has previously been written to
memory as part of an overflow, then a window underflow condition
results. Just like the window overflow, the window underflow
@ -338,7 +338,7 @@ Call and Return Mechanism
The SPARC architecture supports a simple yet
effective call and return mechanism. A subroutine is invoked
via the call (call) instruction. This instruction places the
return address in the caller’s output register 7 (o7). After
return address in the caller's output register 7 (o7). After
the callee executes a save instruction, this value is available
in input register 7 (i7) until the corresponding restore
instruction is executed.
@ -346,7 +346,7 @@ instruction is executed.
The callee returns to the caller via a jmp to the
return address. There is a delay slot following this
instruction which is commonly used to execute a restore
instruction – if a register window was allocated by this
instruction - if a register window was allocated by this
subroutine.
It is important to note that the SPARC subroutine
@ -354,7 +354,7 @@ call and return mechanism does not automatically save and
restore any registers. This is accomplished via the save and
restore instructions which manage the set of registers windows.
This allows for the compiler to generate leaf-optimized functions
that utilize the caller’s output registers without using save and restore.
that utilize the caller's output registers without using save and restore.
Calling Mechanism
-----------------
@ -376,7 +376,7 @@ Parameter Passing
-----------------
RTEMS assumes that arguments are placed in the
caller’s output registers with the first argument in output
caller's output registers with the first argument in output
register 0 (o0), the second argument in output register 1 (o1),
and so forth. Until the callee executes a save instruction, the
parameters are still visible in the output registers. After the
@ -410,7 +410,7 @@ Memory Model
A processor may support any combination of memory
models ranging from pure physical addressing to complex demand
paged virtual memory systems. RTEMS supports a flat memory
model which ranges contiguously over the processor’s allowable
model which ranges contiguously over the processor's allowable
address space. RTEMS does not support segmentation or virtual
memory of any kind. The appropriate memory model for RTEMS
provided by the targeted processor and related characteristics
@ -542,7 +542,7 @@ interrupt handler, then upon receipt of the interrupt, the
processor passes control to the RTEMS interrupt handler which
performs the following actions:
- saves the state of the interrupted task on it’s stack,
- saves the state of the interrupted task on it's stack,
- switches the processor to trap level 0,
@ -597,7 +597,7 @@ execute on the stack of the RTEMS task which they interrupted.
This artificially inflates the stack requirements for each task
since EVERY task stack would have to include enough space to
account for the worst case interrupt stack requirements in
addition to it’s own worst case usage. RTEMS addresses this
addition to it's own worst case usage. RTEMS addresses this
problem on the SPARC by providing a dedicated interrupt stack
managed by software.
@ -661,7 +661,7 @@ to support a particular processor and target board combination.
This chapter presents a discussion of SPARC specific BSP issues.
For more information on developing a BSP, refer to the chapter
titled Board Support Packages in the RTEMS
Applications User’s Guide.
Applications User's Guide.
HelenOS and Open Firmware
-------------------------

4
cpu_supplement/superh.rst
View File

@ -84,8 +84,8 @@ Interrupt Processing
Although RTEMS hides many of the processor dependent
details of interrupt processing, it is important to understand
how the RTEMS interrupt manager is mapped onto the processor’s
unique architecture. Discussed in this chapter are the MIPS’s
how the RTEMS interrupt manager is mapped onto the processor's
unique architecture. Discussed in this chapter are the MIPS's
interrupt response and control mechanisms as they pertain to
RTEMS.

16
develenv/directory.rst
View File

@ -103,7 +103,7 @@ as ``${RTEMS_ROOT}`` in this discussion.
be discussed further in this document.
``${RTEMS_ROOT}/cpukit/``
This directory is the root for all of the "multilib’able"
This directory is the root for all of the "multilib'able"
portions of RTEMS. This is a GNU way of saying the
contents of this directory can be compiled like the
C Library (``libc.a``) and the functionality is
@ -123,7 +123,7 @@ as ``${RTEMS_ROOT}`` in this discussion.
``${RTEMS_ROOT}/make/``
This directory contains files which support the
RTEMS Makefile’s. From a user’s perspective, the
RTEMS Makefile's. From a user's perspective, the
most important parts are found in the ``custom/``
subdirectory. Each ".cfg" file in this directory
is associated with a specific BSP and describes
@ -232,7 +232,7 @@ directory and a description of each.
``${RTEMS_ROOT}/c/src/nfsclient/``
This directory contains a Network File System (NFS) client
for RTEMS. With this file system, a user’s application can
for RTEMS. With this file system, a user's application can
access files on a remote computer.
``${RTEMS_ROOT}/c/src/optman/``
@ -554,10 +554,10 @@ and PostScript.
``${RTEMS_ROOT}/doc/ada_user/``
This directory contains the source code for the *RTEMS
Applications Ada User’s Guide* which documents the Ada95
Applications Ada User's Guide* which documents the Ada95
binding to the Classic API. This manual is produced from
from the same source base as the *RTEMS Application
C User’s Guide*.
C User's Guide*.
``${RTEMS_ROOT}/doc/bsp_howto/``
This directory contains the source code for the*RTEMS BSP and Device Driver Development Guide*.
@ -605,8 +605,8 @@ and PostScript.
This directory contains the source code for the*RTEMS POSIX 1003.1 Compliance Guide*.
``${RTEMS_ROOT}/doc/posix_users/``
This directory contains the source code for the*RTEMS POSIX API User’s Guide*. It is important to
note that RTEMS’ support for POSIX is a combination of
This directory contains the source code for the*RTEMS POSIX API User's Guide*. It is important to
note that RTEMS' support for POSIX is a combination of
functionality provided by RTEMS and the Newlib C Library
so some functionality is documented by Newlib.
@ -628,7 +628,7 @@ and PostScript.
``${RTEMS_ROOT}/doc/user/``
This directory contains the source code for the *RTEMS
Applications C User’s Guide* which documents the Classic API.
Applications C User's Guide* which documents the Classic API.
.. COMMENT: COPYRIGHT (c) 1989-2007.

2
develenv/index.rst
View File

@ -2,7 +2,7 @@
RTEMS Development Environment Guide
===================================
COPYRIGHT © 1988 - 2015.
COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).

6
develenv/sample.rst
View File

@ -129,7 +129,7 @@ The following messages are printed:
Hello World
\*** END OF HELLO WORLD TEST \***
These messages are printed from the application’s
These messages are printed from the application's
single initialization task. If the above messages are not
printed correctly, then either the BSP start up code or the
console output routine is not operating properly.
@ -199,7 +199,7 @@ when using the Ada version to output the following messages:
\*** END OF SAMPLE SINGLE PROCESSOR APPLICATION \***
The first two messages are printed from the
application’s single initialization task. The final messages
application's single initialization task. The final messages
are printed from the single application task.
Base Multiple Processor Application
@ -233,7 +233,7 @@ The second node will print the following messages:
This task has the id of 0x20002
\*** END OF SAMPLE MULTIPROCESSOR APPLICATION \***
The herald is printed from the application’s single
The herald is printed from the application's single
initialization task on each node. The final messages are
printed from the single application task on each node.

4
develenv/utilities.rst
View File

@ -116,7 +116,7 @@ smaller than download.sr.
The source for packhex first appeared in the May 1993
issue of Embedded Systems magazine. The code was downloaded
from their BBS. Unfortunately, the author’s name was not
from their BBS. Unfortunately, the author's name was not
provided in the listing.
.. COMMENT: unhex
@ -133,7 +133,7 @@ unhex - Convert Hexadecimal File into Binary Equivalent
**DESCRIPTION**
unhex accepts Intel Hexadecimal, Motorola Srecord, or
TI ’B’ records and converts them to their binary equivalent.
TI 'B' records and converts them to their binary equivalent.
The output may sent to standout or may be placed in a specified
file with the -o option. The designated output file may not be
an input file. Multiple input files may be specified with their

10
filesystem/call_development.rst
View File

@ -1,10 +1,10 @@
System Call Development Notes
#############################
This set of routines represents the application’s interface to files and directories
This set of routines represents the application's interface to files and directories
under the RTEMS filesystem. All routines are compliant with POSIX standards if a
specific interface has been established. The list below represents the routines that have
been included as part of the application’s interface.
been included as part of the application's interface.
# access()
@ -267,7 +267,7 @@ structure to make it an invalid file descriptor. Apparently the memory
that is about to be freed may still be referenced before it is
reallocated.
The dd_buf structure’s memory is reallocated before the control structure
The dd_buf structure's memory is reallocated before the control structure
that contains the pointer to the dd_buf region.
DIR control memory is reallocated.
@ -629,9 +629,9 @@ rtems_filesystem_is_separator. If it does the search starts from the root
of the RTEMS filesystem; otherwise the search will start from the current
directory.
The OPS table evalformake() function for the parent’s filesystem is used
The OPS table evalformake() function for the parent's filesystem is used
to locate the node that will be the parent of the new link. It will also
locate the start of the new path’s name. This name will be used to define
locate the start of the new path's name. This name will be used to define
a child under the parent directory.
If the parent is found, the routine will determine if the hard link that

10
filesystem/fileystem_implmentation.rst
View File

@ -78,7 +78,7 @@ The following POSIX constraints must be honored by all filesystems.
system cannot be removed.
- On filesystems supporting hard links, a link count is maintained.
Prior to node removal, the node’s link count is decremented by one. The
Prior to node removal, the node's link count is decremented by one. The
link count must be less than one to allow for removal of the node.
API Layering
@ -168,7 +168,7 @@ provided to the application:
# write()
The filesystem’s type as well as the node type within the filesystem
The filesystem's type as well as the node type within the filesystem
determine the nature of the processing that must be performed for each of
the functions above. The RTEMS filesystem provides a framework that
allows new filesystem to be developed and integrated without alteration
@ -634,7 +634,7 @@ const char \*dev
The is intended to contain a string that identifies the device that contains
the filesystem information. The filesystems that are currently implemented
are memory based and don’t require a device specification.
are memory based and don't require a device specification.
If the mt_point_node.node_access is NULL then we are mounting the base file
system.
@ -645,7 +645,7 @@ system.
The node will have read, write and execute permissions for owner, group and
others.
The node’s name will be a null string.
The node's name will be a null string.
A filesystem information structure(fs_info) will be allocated and
initialized for the IMFS filesystem. The fs_info pointer in the mount table
@ -759,7 +759,7 @@ File Handler Table Functions
Handler table functions are defined in a ``rtems_filesystem_file_handlers_r``
structure. It defines functions that are specific to a node type in a given
filesystem. One table exists for each of the filesystem’s node types. The
filesystem. One table exists for each of the filesystem's node types. The
structure definition appears below. It is followed by general developmental
information on each of the functions associated with regular files contained
in this function management structure.

18
filesystem/in-memory.rst
View File

@ -56,10 +56,10 @@ explanation of their role in the filesystem.
is a unique node identification number
*st_uid*
is the user ID of the file’s owner
is the user ID of the file's owner
*st_gid*
is the group ID of the file’s owner
is the group ID of the file's owner
*st_atime*
is the time of the last access to this file
@ -499,7 +499,7 @@ filesystem for the system that contains the mount point. It will determine
if the point that we are trying to mount onto is a node of IMFS_DIRECTORY
type.
If it is the node’s info element is altered so that the info.directory.mt_fs
If it is the node's info element is altered so that the info.directory.mt_fs
element points to the mount table chain entry that is associated with the
mounted filesystem at this point. The info.directory.mt_fs element can be
examined to determine if a filesystem is mounted at a directory. If it is
@ -602,7 +602,7 @@ const char \*dev
The is intended to contain a string that identifies the device that contains
the filesystem information. The filesystems that are currently implemented
are memory based and don’t require a device specification.
are memory based and don't require a device specification.
If the mt_point_node.node_access is NULL then we are mounting the base file
system.
@ -613,7 +613,7 @@ system.
The node will have read, write and execute permissions for owner, group and
others.
The node’s name will be a null string.
The node's name will be a null string.
A filesystem information structure(fs_info) will be allocated and
initialized for the IMFS filesystem. The fs_info pointer in the mount table
@ -658,7 +658,7 @@ This routine allows the IMFS to unmount a filesystem that has been
mounted onto a IMFS directory.
The mount entry mount point node access is verified to be a mounted
directory. It’s mt_fs is set to NULL. This identifies to future
directory. It's mt_fs is set to NULL. This identifies to future
calles into the IMFS that this directory node is no longer a mount
point. Additionally, it will allow any directories that were hidden
by the mounted system to again become visible.
@ -741,7 +741,7 @@ Regular File Handler Table Functions
Handler table functions are defined in a rtems_filesystem_file_handlers_r
structure. It defines functions that are specific to a node type in a given
filesystem. One table exists for each of the filesystem’s node types. The
filesystem. One table exists for each of the filesystem's node types. The
structure definition appears below. It is followed by general developmental
information on each of the functions associated with regular files contained
in this function management structure.
@ -1114,7 +1114,7 @@ Directory Handler Table Functions
Handler table functions are defined in a rtems_filesystem_file_handlers_r
structure. It defines functions that are specific to a node type in a given
filesystem. One table exists for each of the filesystem’s node types. The
filesystem. One table exists for each of the filesystem's node types. The
structure definition appears below. It is followed by general developmental
information on each of the functions associated with directories contained in
this function management structure.
@ -1467,7 +1467,7 @@ Device Handler Table Functions
Handler table functions are defined in a rtems_filesystem_file_handlers_r
structure. It defines functions that are specific to a node type in a given
filesystem. One table exists for each of the filesystem’s node types. The
filesystem. One table exists for each of the filesystem's node types. The
structure definition appears below. It is followed by general developmental
information on each of the functions associated with devices contained in
this function management structure.

2
filesystem/index.rst
View File

@ -2,7 +2,7 @@
RTEMS Filesystem Design Guide
=============================
COPYRIGHT © 1988 - 2015.
COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).

4
filesystem/pathname_eval.rst
View File

@ -66,8 +66,8 @@ parsed.
*node_access*
This element is filesystem specific. A filesystem can define and store
any information necessary to identify a node at this location. This element
is normally filled in by the filesystem’s evaluate routine. For the
filesystem’s root node, the filesystem’s initilization routine should
is normally filled in by the filesystem's evaluate routine. For the
filesystem's root node, the filesystem's initilization routine should
fill this in, and it should remain valid until the instance of the
filesystem is unmounted.

16
filesystem/system_init.rst
View File

@ -1,16 +1,16 @@
System Initialization
#####################
After the RTEMS initialization is performed, the application’s
After the RTEMS initialization is performed, the application's
initialization will be performed. Part of initialization is a call to
rtems_filesystem_initialize(). This routine will mount the ‘In Memory File
System’ as the base filesystem. Mounting the base filesystem consists
rtems_filesystem_initialize(). This routine will mount the 'In Memory File
System' as the base filesystem. Mounting the base filesystem consists
of the following:
- Initialization of mount table chain control structure
- Allocation of a ``jnode`` structure that will server as the root node
of the ‘In Memory Filesystem’
of the 'In Memory Filesystem'
- Initialization of the allocated ``jnode`` with the appropriate OPS,
directory handlers and pathconf limits and options.
@ -36,7 +36,7 @@ Base Filesystem
RTEMS initially mounts a RAM based file system known as the base file system.
The root directory of this file system tree serves as the logical root of the
directory hierarchy (Figure 3). Under the root directory a ‘/dev’ directory
directory hierarchy (Figure 3). Under the root directory a '/dev' directory
is created under which all I/O device directories and files are registered as
part of the file system hierarchy.
.. code:: c
@ -61,8 +61,8 @@ required to manage the future file systems.
Base Filesystem Mounting
------------------------
At present, the first file system to be mounted is the ‘In Memory File
System’. It is mounted using a standard MOUNT() command in which the mount
At present, the first file system to be mounted is the 'In Memory File
System'. It is mounted using a standard MOUNT() command in which the mount
point is NULL. This flags the mount as the first file system to be
registered under the operating system and appropriate initialization of file
system management information is performed (See figures 4 and 5). If a
@ -81,7 +81,7 @@ system (See ioman.c) a device registration process is performed. Device
registration produces a unique dev_t handle that consists of a major and
minor device number. In addition, the configuration information for each
device contains a text string that represents the fully qualified pathname to
that device’s place in the base file system’s hierarchy. A file system node
that device's place in the base file system's hierarchy. A file system node
is created for the device along the specified registration path.
.. code:: c

4
networking/dec_21140.rst
View File

@ -46,7 +46,7 @@ DEC21140 PCI Board Generalities
This chapter describes rapidely the PCI interface of this Ethernet controller.
The board we have chosen for our PC386 implementation is a D-Link DFE-500TX.
This is a dual-speed 10/100Mbps Ethernet PCI adapter with a DEC21140AF chip.
Like other PCI devices, this board has a PCI device’s header containing some
Like other PCI devices, this board has a PCI device's header containing some
required configuration registers, as shown in the PCI Register Figure.
By reading
or writing these registers, a driver can obtain information about the type of
@ -132,7 +132,7 @@ Receiver Thread
---------------
This thread is event driven. Each time a DEC PCI board interrupt occurs, the
handler checks if this is a receive interrupt and send an event “reception”
handler checks if this is a receive interrupt and send an event "reception"
to the receiver thread which looks into the entire buffer descriptors ring the
ones that contain a valid incoming frame (bit OWN=0 means descriptor belongs
to host processor). Each valid incoming ethernet frame is sent to the protocol

2
networking/index.rst
View File

@ -1,7 +1,7 @@
========================
RTEMS Network Supplement
========================
COPYRIGHT © 1988 - 2015.
COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).

2
networking/network_servers.rst
View File

@ -6,7 +6,7 @@ RTEMS FTP Daemon
The RTEMS FTPD is a complete file transfer protocol (FTP) daemon
which can store, retrieve, and manipulate files on the local
filesystem. In addition, the RTEMS FTPD provides “hooks”
filesystem. In addition, the RTEMS FTPD provides "hooks"
which are actions performed on received data. Hooks are useful
in situations where a destination file is not necessarily
appropriate or in cases when a formal device driver has not yet

2
networking/network_task_structure.rst
View File

@ -23,7 +23,7 @@ The network task processes incoming packets and takes care of
timed operations such as handling TCP timeouts and
aging and removing routing table entries.
The ‘Network code’ contains routines which may run in the context of
The 'Network code' contains routines which may run in the context of
the user application tasks, the interface receive task or the network task.
A network semaphore ensures that
the data structures manipulated by the network code remain consistent.

18
networking/networking_driver.rst
View File

@ -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.
@ -160,9 +160,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
@ -211,7 +211,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.
@ -221,8 +221,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.

2
networking/preface.rst
View File

@ -11,7 +11,7 @@ who also ported the FreeBSD TCP/IP stack to RTEMS.
The following is a list of resources which should be useful in trying
to understand Ethernet:
- *Charles Spurgeon’s Ethernet Web Site*
- *Charles Spurgeon's Ethernet Web Site*
"This site provides extensive information about Ethernet
(IEEE 802.3) local area network (LAN) technology. Including
the original 10 Megabit per second (Mbps) system, the 100 Mbps

44
networking/testing_the_driver.rst
View File

@ -11,7 +11,7 @@ The network used to test the driver should include at least:
the operation of the target machine.
- An Ethernet network analyzer or a workstation with an
‘Ethernet snoop’ program such as ``ethersnoop`` or``tcpdump``.
'Ethernet snoop' program such as ``ethersnoop`` or``tcpdump``.
- A workstation.
@ -39,7 +39,7 @@ is a list of them:
- mbuf activity
There are commented out calls to ``printf`` in the file``sys/mbuf.h`` in the network stack code. Uncommenting
these lines results in output when mbuf’s are allocated
these lines results in output when mbuf's are allocated
and freed. This is very useful for finding memory leaks.
- TX and RX queuing
@ -91,29 +91,29 @@ is a list of them:
URL: (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-routing.html)
For a quick reference to the flags, see the table below:
‘``U``’
'``U``'
Up: The route is active.
‘``H``’
'``H``'
Host: The route destination is a single host.
‘``G``’
'``G``'
Gateway: Send anything for this destination on to this remote system, which
will figure out from there where to send it.
‘``S``’
'``S``'
Static: This route was configured manually, not automatically generated by the
system.
‘``C``’
'``C``'
Clone: Generates a new route based upon this route for machines we connect
to. This type of route is normally used for local networks.
‘``W``’
'``W``'
WasCloned: Indicated a route that was auto-configured based upon a local area
network (Clone) route.
‘``L``’
'``L``'
Link: Route involves references to Ethernet hardware.
- ``mbuf``
@ -182,29 +182,29 @@ The network demonstration program ``netdemo`` may be used for these tests.
broadcast packets disabled:
Verify that the program continues to run once the driver has been attached.
- Issue a ‘``u``’ command to send UDP
packets to the ‘discard’ port.
- Issue a '``u``' command to send UDP
packets to the 'discard' port.
Verify that the packets appear on the network.
- Issue a ‘``s``’ command to print the network and driver statistics.
- Issue a '``s``' command to print the network and driver statistics.
- On a workstation, add a static route to the target system.
- On that same workstation try to ‘ping’ the target system.
- On that same workstation try to 'ping' the target system.
Verify that the ICMP echo request and reply packets appear on the net.
- Remove the static route to the target system.
Modify ``networkconfig.h`` to attach the driver
with reception of broadcast packets enabled.
Try to ‘ping’ the target system again.
Try to 'ping' the target system again.
Verify that ARP request/reply and ICMP echo request/reply packets appear
on the net.
- Issue a ‘``t``’ command to send TCP
packets to the ‘discard’ port.
- Issue a '``t``' command to send TCP
packets to the 'discard' port.
Verify that the packets appear on the network.
- Issue a ‘``s``’ command to print the network and driver statistics.
- Issue a '``s``' command to print the network and driver statistics.
- Verify that you can telnet to ports 24742
and 24743 on the target system from one or more
@ -232,7 +232,7 @@ Giant packets
- Recompile the driver with ``MAXIMUM_FRAME_SIZE`` set to
a smaller value, say 514.
- ‘Ping’ the driver from another workstation and verify
- 'Ping' the driver from another workstation and verify
that frames larger than 514 bytes are correctly rejected.
- Recompile the driver with ``MAXIMUM_FRAME_SIZE`` restored to 1518.
@ -248,8 +248,8 @@ Resource Exhaustion
- Verify that the program operates properly and that you can
still telnet to both the ports.
- Display the driver statistics (Console ‘``s``’ command or telnet
‘control-G’ character) and verify that:
- Display the driver statistics (Console '``s``' command or telnet
'control-G' character) and verify that:
# The number of transmit interrupts is non-zero.
This indicates that all transmit descriptors have been in use at some time.
@ -262,7 +262,7 @@ Cable Faults
- Run the ``netdemo`` program.
- Issue a ‘``u``’ console command to make the target machine transmit
- Issue a '``u``' console command to make the target machine transmit
a bunch of UDP packets.
- While the packets are being transmitted, disconnect and reconnect the
@ -277,7 +277,7 @@ Throughput
----------
Run the ``ttcp`` network benchmark program.
Transfer large amounts of data (100’s of megabytes) to and from the target
Transfer large amounts of data (100's of megabytes) to and from the target
system.
The procedure for testing throughput from a host to an RTEMS target

16
networking/using_networking_rtems_app.rst
View File

@ -126,7 +126,7 @@ below, you need to provide only the first two entries in this structure.
You can also use ``rtems_bsdnet_do_bootp_rootfs`` to have a set of
standard files created with the information return by the BOOTP/DHCP
protocol. The IP address is added to :file:`/etc/hosts` with the host
name and domain returned. If no host name or domain is returned``me.mydomain`` is used. The BOOTP/DHCP server’s address is also
name and domain returned. If no host name or domain is returned``me.mydomain`` is used. The BOOTP/DHCP server's address is also
added to :file:`/etc/hosts`. The domain name server listed in the
BOOTP/DHCP information are added to :file:`/etc/resolv.conf`. A``search`` record is also added if a domain is returned. The files
are created if they do not exist.
@ -162,7 +162,7 @@ below, you need to provide only the first two entries in this structure.
``char \*gateway``
The Internet host number of the network gateway machine,
specified in ’dotted decimal’ (``129.128.4.1``) form.
specified in 'dotted decimal' (``129.128.4.1``) form.
``char \*log_host``
The Internet host number of the machine to which ``syslog`` messages
@ -279,13 +279,13 @@ structure.
``char \*ip_address``
The Internet address of the device,
specified in ‘dotted decimal’ (``129.128.4.2``) form, or ``NULL``
specified in 'dotted decimal' (``129.128.4.2``) form, or ``NULL``
if the device configuration information is being obtained from a
BOOTP/DHCP server.
``char \*ip_netmask``
The Internet inetwork mask of the device,
specified in ‘dotted decimal’ (``255.255.255.0``) form, or ``NULL``
specified in 'dotted decimal' (``255.255.255.0``) form, or ``NULL``
if the device configuration information is being obtained from a
BOOTP/DHCP server.
@ -496,8 +496,8 @@ you when more data has arrived. (Condition 1.a.)
For sending, when the socket is connected and the free space becomes at
or above the "low water mark" for the send buffer (default 4096 bytes)
you will receive a writable callback. You don’t get continuous callbacks
if you don’t write anything. Using a non-blocking write socket, you can
you will receive a writable callback. You don't get continuous callbacks
if you don't write anything. Using a non-blocking write socket, you can
then call write until it returns a value less than the amount of data
requested to be sent or it produces error EWOULDBLOCK (indicating buffer
full and no longer writable). When this happens you can
@ -837,13 +837,13 @@ returns. The priority argument is ignored.
If the interval argument is greater than 0, the routine also starts an
RTEMS task at the specified priority and polls the NTP server every
‘interval’ seconds. NOTE: This mode of operation has not yet been
'interval' seconds. NOTE: This mode of operation has not yet been
implemented.
On successful synchronization of the RTEMS time-of-day clock the routine
returns 0. If an error occurs a message is printed and the routine returns -1
with an error code in errno.
There is no timeout – if there is no response from an NTP server the
There is no timeout - if there is no response from an NTP server the
routine will wait forever.
.. COMMENT: Written by Eric Norum

2
porting/code_tuning.rst
View File

@ -87,7 +87,7 @@ Data Alignment Requirements
Data Element Alignment
----------------------
The CPU_ALIGNMENT macro should be set to the CPU’s worst alignment
The CPU_ALIGNMENT macro should be set to the CPU's worst alignment
requirement for data types on a byte boundary. This is typically the
alignment requirement for a C double. This alignment does not take into
account the requirements for the stack.

2
porting/cpu_init.rst
View File

@ -38,7 +38,7 @@ During the initialization of the context for tasks with floating point,
the CPU dependent code is responsible for initializing the floating point
context. If there is not an easy way to initialize the FP context during
Context_Initialize, then it is usually easier to save an "uninitialized"
FP context here and copy it to the task’s during Context_Initialize. If
FP context here and copy it to the task's during Context_Initialize. If
this technique is used to initialize the FP contexts, then it is important
to ensure that the state of the floating point unit is in a coherent,
initialized state.

4
porting/cpu_model_variations.rst
View File

@ -105,8 +105,8 @@ processor families is not enough to address the needs of embedded systems
developers. Custom board development is the norm for embedded systems.
Each of these boards is optimized for a particular project. The processor
and peripheral set have been chosen to meet a particular set of system
requirements. The tools in the embedded systems developers’ toolbox must
support their project’s unique board. RTEMS addresses this issue via the
requirements. The tools in the embedded systems developers toolbox must
support their project's unique board. RTEMS addresses this issue via the
Board Support Package.
RTEMS segregates board specific code to make it possible for the embedded

2
porting/idle_thread.rst
View File

@ -86,7 +86,7 @@ self" which is implemented in a routine as follows.
}
If the CPU dependent IDLE thread body is implementation centers upon using
a "halt", "idle", or "shutdown" instruction, then don’t forget to put it
a "halt", "idle", or "shutdown" instruction, then don't forget to put it
in an infinite loop as the CPU will have to reexecute this instruction
each time the IDLE thread is dispatched.
.. code:: c

2
porting/index.rst
View File

@ -1,7 +1,7 @@
===================
RTEMS Porting Guide
===================
COPYRIGHT © 1988 - 2015.
COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).

4
porting/interrupts.rst
View File

@ -305,7 +305,7 @@ The ``_ISR_Handler`` routine provides the RTEMS interrupt management.
This discussion ignores a lot of the ugly details in a real implementation
such as saving enough registers/state to be able to do something real.
Keep in mind that the goal is to invoke a user’s ISR handler which is
Keep in mind that the goal is to invoke a user's ISR handler which is
written in C. That ISR handler uses a known set of registers thus
allowing the ISR to preserve only those that would normally be corrupted
by a subroutine call.
@ -368,7 +368,7 @@ specific wrapper for ``_Thread_Dispatch`` used in this case.
ISR Invoked with Frame Pointer
------------------------------
Does the RTEMS invoke the user’s ISR with the vector number and a pointer
Does the RTEMS invoke the user's ISR with the vector number and a pointer
to the saved interrupt frame (1) or just the vector number (0)?
.. code:: c

10
porting/miscellanous.rst
View File

@ -5,7 +5,7 @@ Fatal Error Default Handler
===========================
The ``_CPU_Fatal_halt`` routine is the default fatal error handler. This
routine copies _error into a known place – typically a stack location or
routine copies _error into a known place - typically a stack location or
a register, optionally disables interrupts, and halts/stops the CPU. It
is prototyped as follows and is often implemented as a macro:
.. code:: c
@ -100,8 +100,8 @@ single instruction (e.g. i486). It is probably best to avoid an "endian
swapping control bit" in the CPU. One good reason is that interrupts
would probably have to be disabled to insure that an interrupt does not
try to access the same "chunk" with the wrong endian. Another good reason
is that on some CPUs, the endian bit endianness for ALL fetches – both
code and data – so the code will be fetched incorrectly.
is that on some CPUs, the endian bit endianness for ALL fetches - both
code and data - so the code will be fetched incorrectly.
The following is an implementation of the ``CPU_swap_u32`` routine that will
work on any CPU. It operates by breaking the unsigned thirty-two bit
@ -142,8 +142,8 @@ single instruction (e.g. i486). It is probably best to avoid an "endian
swapping control bit" in the CPU. One good reason is that interrupts
would probably have to be disabled to insure that an interrupt does not
try to access the same "chunk" with the wrong endian. Another good reason
is that on some CPUs, the endian bit endianness for ALL fetches – both
code and data – so the code will be fetched incorrectly.
is that on some CPUs, the endian bit endianness for ALL fetches - both
code and data - so the code will be fetched incorrectly.
Similarly, here is a portable implementation of the ``CPU_swap_u16``
routine. Just as with the ``CPU_swap_u32`` routine, the porter

6
porting/priority_bitmap.rst
View File

@ -85,8 +85,8 @@ major/minor) is the first bit found.
This entire "find first bit" and mapping process depends heavily on the
manner in which a priority is broken into a major and minor components
with the major being the 4 MSB of a priority and minor the 4 LSB. Thus (0
<< 4) + 0 corresponds to priority 0 – the highest priority. And (15 <<
4) + 14 corresponds to priority 254 – the next to the lowest priority.
<< 4) + 0 corresponds to priority 0 - the highest priority. And (15 <<
4) + 14 corresponds to priority 254 - the next to the lowest priority.
If your CPU does not have a "find first bit" instruction, then there are
ways to make do without it. Here are a handful of ways to implement this
@ -94,7 +94,7 @@ in software:
- a series of 16 bit test instructions
- a "binary search using if’s"
- a "binary search using if's"
- the following algorithm based upon a 16 entry lookup table. In this pseudo-code, bit_set_table[16] has values which indicate the first bit set:

12
porting/task_context.rst
View File

@ -200,15 +200,15 @@ and ``_CPU_Context_switch`` will return to its caller.
Care should be exercise when writing this routine. All
registers assumed to be preserved across subroutine calls
must be preserved. These registers may be saved in
the task’s context area or on its stack. However, the
the task's context area or on its stack. However, the
stack pointer and address to resume executing the task
at must be included in the context (normally the subroutine
return address to the caller of ``_Thread_Dispatch``.
The decision of where to store the task’s context is based
The decision of where to store the task's context is based
on numerous factors including the capabilities of
the CPU architecture itself and simplicity as well
as external considerations such as debuggers wishing
to examine a task’s context. In this case, it is
to examine a task's context. In this case, it is
often simpler to save all data in the context area.
Also there may be special considerations
@ -292,7 +292,7 @@ is varying) macro is set based on the CPU family dependent macro.
The macro name THIS_CPU_FAMILY_HAS_FPU should be made CPU specific. It
indicates whether or not this CPU model has FP support. For example, the
definition of the i386ex and i386sx CPU models would set I386_HAS_FPU to
FALSE to indicate that these CPU models are i386’s without an i387 and
FALSE to indicate that these CPU models are i386's without an i387 and
wish to leave floating point support out of RTEMS when built for the
i386_nofp processor model. On a CPU with a built-in FPU like the i486,
this would be defined as TRUE.
@ -399,7 +399,7 @@ point context is dumped by a "FP save context" type instruction and the
format is either not completely defined by the CPU documentation or the
format is not critical for the implementation of the floating point
context switch routines. In this case, there is no need to figure out the
exact format – only the size. Of course, although this is enough
exact format - only the size. Of course, although this is enough
information for RTEMS, it is probably not enough for a debugger such as
gdb. But that is another problem.
.. code:: c
@ -416,7 +416,7 @@ Size of Floating Point Context Macro
The CPU_CONTEXT_FP_SIZE macro is set to the size of the floating point
context area. On some CPUs this will not be a "sizeof" because the format
of the floating point area is not defined – only the size is. This is
of the floating point area is not defined - only the size is. This is
usually on CPUs with a "floating point save context" instruction. In
general, though it is easier to define the structure as a "sizeof"
operation and define the Context_Control_fp structure to be an area of

2
posix1003_1/files_and_directories.rst
View File

@ -243,7 +243,7 @@ Get Configurable Pathname Variables
NOTE: The newlib unistd.h and sys/unistd.h are installed and the
include search patch is used to get the right one. There are
conflicts between the newlib unistd.h and RTEMS’ version.
conflicts between the newlib unistd.h and RTEMS' version.
.. COMMENT: COPYRIGHT (c) 1988-2002.

2
posix1003_1/index.rst
View File

@ -2,7 +2,7 @@
RTEMS POSIX 1003.1 Compliance Guide
===================================
COPYRIGHT © 1988 - 2015.
COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).

18
posix1003_1/language_specific_services.rst
View File

@ -4,12 +4,12 @@ Language-Specific Services for the C Programming Language
Referenced C Language Routines
==============================
ANSI C Section 4.2 — Diagnostics
ANSI C Section 4.2 - Diagnostics
.. code:: c
assert(), Function, Implemented
ANSI C Section 4.3 — Character Handling
ANSI C Section 4.3 - Character Handling
.. code:: c
isalnum(), Function, Implemented
@ -26,12 +26,12 @@ ANSI C Section 4.3 — Character Handling
tolower(), Function, Implemented
toupper(), Function, Implemented
ANSI C Section 4.4 — Localization
ANSI C Section 4.4 - Localization
.. code:: c
setlocale(), Function, Implemented
ANSI C Section 4.5 — Mathematics
ANSI C Section 4.5 - Mathematics
.. code:: c
acos(), Function, Implemented
@ -57,13 +57,13 @@ ANSI C Section 4.5 — Mathematics
floor(), Function, Implemented
fmod(), Function, Implemented
ANSI C Section 4.6 — Non-Local Jumps
ANSI C Section 4.6 - Non-Local Jumps
.. code:: c
setjmp(), Function, Implemented
longjmp(), Function, Implemented
ANSI C Section 4.9 — Input/Output
ANSI C Section 4.9 - Input/Output
.. code:: c
FILE, Type, Implemented
@ -105,7 +105,7 @@ ANSI C Section 4.9 — Input/Output
NOTE: ``rename`` is also included in another section. `Rename a File`_.
ANSI C Section 4.10 — General Utilities
ANSI C Section 4.10 - General Utilities
.. code:: c
abs(), Function, Implemented
@ -125,7 +125,7 @@ ANSI C Section 4.10 — General Utilities
NOTE: ``getenv`` is also included in another section. `Environment Access`_.
ANSI C Section 4.11 — String Handling
ANSI C Section 4.11 - String Handling
.. code:: c
strcpy(), Function, Implemented
@ -143,7 +143,7 @@ ANSI C Section 4.11 — String Handling
strtok(), Function, Implemented
strlen(), Function, Implemented
ANSI C Section 4.12 — Date and Time Handling
ANSI C Section 4.12 - Date and Time Handling
.. code:: c
asctime(), Function, Implemented

24
posix1003_1/posix1003_1.rst
View File

@ -58,7 +58,7 @@ RTEMS POSIX 1003.1 Compliance Guide
.. COMMENT: can force the copyright description onto a left hand page.
COPYRIGHT © 1988 - 2015.
COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).
@ -293,7 +293,7 @@ C Language Limits
ULONG_MAX, Constant, Implemented
USHRT_MAX, Constant, Implemented
NOTE: These are implemented in GCC’s limits.h file.
NOTE: These are implemented in GCC's limits.h file.
Minimum Values
--------------
@ -1138,7 +1138,7 @@ Get Configurable Pathname Variables
NOTE: The newlib unistd.h and sys/unistd.h are installed and the
include search patch is used to get the right one. There are
conflicts between the newlib unistd.h and RTEMS’ version.
conflicts between the newlib unistd.h and RTEMS' version.
.. COMMENT: COPYRIGHT (c) 1988-2002.
@ -1580,12 +1580,12 @@ Language-Specific Services for the C Programming Language
Referenced C Language Routines
==============================
ANSI C Section 4.2 — Diagnostics
ANSI C Section 4.2 - Diagnostics
.. code:: c
assert(), Function, Implemented
ANSI C Section 4.3 — Character Handling
ANSI C Section 4.3 - Character Handling
.. code:: c
isalnum(), Function, Implemented
@ -1602,12 +1602,12 @@ ANSI C Section 4.3 — Character Handling
tolower(), Function, Implemented
toupper(), Function, Implemented
ANSI C Section 4.4 — Localization
ANSI C Section 4.4 - Localization
.. code:: c
setlocale(), Function, Implemented
ANSI C Section 4.5 — Mathematics
ANSI C Section 4.5 - Mathematics
.. code:: c
acos(), Function, Implemented
@ -1633,13 +1633,13 @@ ANSI C Section 4.5 — Mathematics
floor(), Function, Implemented
fmod(), Function, Implemented
ANSI C Section 4.6 — Non-Local Jumps
ANSI C Section 4.6 - Non-Local Jumps
.. code:: c
setjmp(), Function, Implemented
longjmp(), Function, Implemented
ANSI C Section 4.9 — Input/Output
ANSI C Section 4.9 - Input/Output
.. code:: c
FILE, Type, Implemented
@ -1681,7 +1681,7 @@ ANSI C Section 4.9 — Input/Output
NOTE: ``rename`` is also included in another section. `Rename a File`_.
ANSI C Section 4.10 — General Utilities
ANSI C Section 4.10 - General Utilities
.. code:: c
abs(), Function, Implemented
@ -1701,7 +1701,7 @@ ANSI C Section 4.10 — General Utilities
NOTE: ``getenv`` is also included in another section. `Environment Access`_.
ANSI C Section 4.11 — String Handling
ANSI C Section 4.11 - String Handling
.. code:: c
strcpy(), Function, Implemented
@ -1719,7 +1719,7 @@ ANSI C Section 4.11 — String Handling
strtok(), Function, Implemented
strlen(), Function, Implemented
ANSI C Section 4.12 — Date and Time Handling
ANSI C Section 4.12 - Date and Time Handling
.. code:: c
asctime(), Function, Implemented

2
posix1003_1/terminology.rst
View File

@ -131,7 +131,7 @@ C Language Limits
ULONG_MAX, Constant, Implemented
USHRT_MAX, Constant, Implemented
NOTE: These are implemented in GCC’s limits.h file.
NOTE: These are implemented in GCC's limits.h file.
Minimum Values
--------------

4
posix_users/clock.rst
View File

@ -41,8 +41,8 @@ There is currently no text in this section.
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.

4
posix_users/condition_variable.rst
View File

@ -41,8 +41,8 @@ There is currently no text in this section.
Directives
==========
This section details the condition variable manager’s directives.
A subsection is dedicated to each of this manager’s directives
This section details the condition variable 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.

4
posix_users/device_and_class_specific.rst
View File

@ -46,8 +46,8 @@ There is currently no text in this section.
Directives
==========
This section details the device- and class- specific functions manager’s
directives. A subsection is dedicated to each of this manager’s directives
This section details the device- and class- specific functions 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.

46
posix_users/files_and_directory.rst
View File

@ -103,8 +103,8 @@ There is currently no text in this section.
Directives
==========
This section details the files and directories manager’s directives.
A subsection is dedicated to each of this manager’s directives
This section details the files and directories 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.
@ -342,7 +342,7 @@ On error, this routine returns -1 and sets ``errno`` to one of
the following:
*EACCES*
Search permission is denied for a directory in a file’s path prefix.
Search permission is denied for a directory in a file's path prefix.
*ENAMETOOLONG*
Length of a filename string exceeds PATH_MAX and _POSIX_NO_TRUNC is
@ -388,7 +388,7 @@ On error, this routine returns -1 and sets ``errno`` to one of
the following:
*EACCES*
Search permission is denied for a directory in a file’s path prefix.
Search permission is denied for a directory in a file's path prefix.
*ENAMETOOLONG*
Length of a filename string exceeds PATH_MAX and _POSIX_NO_TRUNC is
@ -435,7 +435,7 @@ getcwd - Gets current working directory
Result is too large
*EACCES*
Search permission is denied for a directory in a file’s path prefix.
Search permission is denied for a directory in a file's path prefix.
**DESCRIPTION:**
@ -475,7 +475,7 @@ open - Opens a file
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix.
Search permission is denied for a directory in a file's path prefix.
*EEXIST*
The named file already exists.
@ -695,7 +695,7 @@ link - Creates a link to a file
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix
Search permission is denied for a directory in a file's path prefix
*EEXIST*
The named file already exists.
@ -760,7 +760,7 @@ symlink - Creates a symbolic link to a file
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix
Search permission is denied for a directory in a file's path prefix
*EEXIST*
The named file already exists.
@ -818,7 +818,7 @@ readlink - Obtain the name of a symbolic link destination
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix
Search permission is denied for a directory in a file's path prefix
*ENAMETOOLONG*
Length of a filename string exceeds PATH_MAX and _POSIX_NO_TRUNC is in
@ -870,7 +870,7 @@ mkdir - Makes a directory
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix
Search permission is denied for a directory in a file's path prefix
*EEXIST*
The name file already exist.
@ -928,7 +928,7 @@ mkfifo - Makes a FIFO special file
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix
Search permission is denied for a directory in a file's path prefix
*EEXIST*
The named file already exists.
@ -973,7 +973,7 @@ unlink - Removes a directory entry
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix
Search permission is denied for a directory in a file's path prefix
*EBUSY*
The directory is in use.
@ -1032,11 +1032,11 @@ rmdir - Delete a directory
*EACCES*
Write access to the directory containing ``pathname`` was not
allowed for the process’s effective uid, or one of the directories in``pathname`` did not allow search (execute) permission.
allowed for the process's effective uid, or one of the directories in``pathname`` did not allow search (execute) permission.
*EPERM*
The directory containing ``pathname`` has the stickybit (S_ISVTX)
set and the process’s effective uid is neither the uid of the file to
set and the process's effective uid is neither the uid of the file to
be delected nor that of the director containing it.
*ENAMETOOLONG*
@ -1096,7 +1096,7 @@ rename - Renames a file
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix.
Search permission is denied for a directory in a file's path prefix.
*EBUSY*
The directory is in use.
@ -1174,7 +1174,7 @@ stat - Gets information about a file
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix.
Search permission is denied for a directory in a file's path prefix.
*EBADF*
Invalid file descriptor.
@ -1343,7 +1343,7 @@ chmod - Changes file mode.
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix
Search permission is denied for a directory in a file's path prefix
*ENAMETOOLONG*
Length of a filename string exceeds PATH_MAX and _POSIX_NO_TRUNC is in
@ -1393,7 +1393,7 @@ fchmod - Changes permissions of a file
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix.
Search permission is denied for a directory in a file's path prefix.
*EBADF*
The descriptor is not valid.
@ -1464,7 +1464,7 @@ and ``errno`` is set appropriately.
Invalid file descriptor ``fd``.
*EFAULT*
Argument points outside the calling process’s address space.
Argument points outside the calling process's address space.
*EINVAL*
Result buffer is too small.
@ -1505,7 +1505,7 @@ chown - Changes the owner and/or group of a file.
**STATUS CODES:**
*EACCES*
Search permission is denied for a directory in a file’s path prefix
Search permission is denied for a directory in a file's path prefix
*EINVAL*
Invalid argument
@ -1634,7 +1634,7 @@ ftruncate - truncate a file to a specified length
An I/O error occurred updating the inode.
*EFAULT*
``Path`` points outside the process’s allocated address space.
``Path`` points outside the process's allocated address space.
*EBADF*
The ``fd`` is not a valid descriptor.
@ -1702,7 +1702,7 @@ truncate - truncate a file to a specified length
An I/O error occurred updating the inode.
*EFAULT*
``Path`` points outside the process’s allocated address space.
``Path`` points outside the process's allocated address space.
*EBADF*
The ``fd`` is not a valid descriptor.
@ -1919,7 +1919,7 @@ named pipe) named ``pathname``, specified by ``mode`` and ``dev``.
It should be a combination (using bitwise OR) of one of the file types listed
below and the permissions for the new node.
The permissions are modified by the process’s ``umask`` in the usual way: the
The permissions are modified by the process's ``umask`` in the usual way: the
permissions of the created node are ``(mode & ~umask)``.
The file type should be one of ``S_IFREG``, ``S_IFCHR``, ``S_IFBLK`` and``S_IFIFO`` to specify a normal file (which will be created empty), character

4
posix_users/index.rst
View File

@ -1,8 +1,8 @@
============================
RTEMS POSIX API User’s Guide
RTEMS POSIX API User's Guide
============================
COPYRIGHT © 1988 - 2015.
COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).

Some files were not shown because too many files have changed in this diff Show More