diff options
Diffstat (limited to 'porting')
-rw-r--r-- | porting/code_tuning.rst | 2 | ||||
-rw-r--r-- | porting/cpu_init.rst | 2 | ||||
-rw-r--r-- | porting/cpu_model_variations.rst | 4 | ||||
-rw-r--r-- | porting/idle_thread.rst | 2 | ||||
-rw-r--r-- | porting/index.rst | 2 | ||||
-rw-r--r-- | porting/interrupts.rst | 4 | ||||
-rw-r--r-- | porting/miscellanous.rst | 10 | ||||
-rw-r--r-- | porting/priority_bitmap.rst | 6 | ||||
-rw-r--r-- | porting/task_context.rst | 12 |
9 files changed, 22 insertions, 22 deletions
diff --git a/porting/code_tuning.rst b/porting/code_tuning.rst index 8090cab..e28bdd7 100644 --- a/porting/code_tuning.rst +++ b/porting/code_tuning.rst @@ -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. diff --git a/porting/cpu_init.rst b/porting/cpu_init.rst index 0406c35..f880cab 100644 --- a/porting/cpu_init.rst +++ b/porting/cpu_init.rst @@ -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. diff --git a/porting/cpu_model_variations.rst b/porting/cpu_model_variations.rst index 797a009..851df1f 100644 --- a/porting/cpu_model_variations.rst +++ b/porting/cpu_model_variations.rst @@ -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 projects 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 diff --git a/porting/idle_thread.rst b/porting/idle_thread.rst index 18ac5ce..7bba283 100644 --- a/porting/idle_thread.rst +++ b/porting/idle_thread.rst @@ -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 diff --git a/porting/index.rst b/porting/index.rst index 982d2a6..346a463 100644 --- a/porting/index.rst +++ b/porting/index.rst @@ -1,7 +1,7 @@ =================== RTEMS Porting Guide =================== -COPYRIGHT © 1988 - 2015. +COPYRIGHT (c) 1988 - 2015. On-Line Applications Research Corporation (OAR). diff --git a/porting/interrupts.rst b/porting/interrupts.rst index d6958ab..8a69e1a 100644 --- a/porting/interrupts.rst +++ b/porting/interrupts.rst @@ -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 diff --git a/porting/miscellanous.rst b/porting/miscellanous.rst index 9bbd712..01073f7 100644 --- a/porting/miscellanous.rst +++ b/porting/miscellanous.rst @@ -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 diff --git a/porting/priority_bitmap.rst b/porting/priority_bitmap.rst index 36c294b..7b24451 100644 --- a/porting/priority_bitmap.rst +++ b/porting/priority_bitmap.rst @@ -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: diff --git a/porting/task_context.rst b/porting/task_context.rst index 62626ed..ec2d1e0 100644 --- a/porting/task_context.rst +++ b/porting/task_context.rst @@ -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 |