RAM 6.0 BUX II Series Guía de usuario descargar pdf (Pagina 143)

A Common Development Issues

A.4 Reusing Unportable Code

135

A.4 Reusing Unportable Code

A common problem when creating BSPs is that code for some devices may have

been taken from other sources, and that code may not have been written with

portability in mind.

When using code from other sources, you can prevent problems by examining the

code for portability before including it in your BSP. For information about issues

related to writing portable code, refer to the VxWorks Hardware Interface Validation

Guide.

A.5 Volatile Variables

Normally, a compiler is allowed to generate code that maintains copies of any

variable in a register, so that the variable does not need to be fetched from memory

multiple times. For most application code, this is appropriate behavior. However,

for many global variables in BSPs and drivers, there are multiple threads that

access the variables, and maintaining a local copy in a register may cause

problems.

All variables that are used from more than one thread, including software threads

on the main processor and threads of execution on external devices, should be

declared using the volatile keyword of C. At the time of this writing, current

practice for VxWorks is to use a compiler argument indicating that all BSP and

driver variables are to be treated this way, it is nevertheless recommended that all

variables manipulated by multiple threads be explicitly marked as volatile.

A.6 Conflicts Between Virtual and Physical Memory

With VxWorks 5.5 and earlier, VxWorks typically used a flat memory model, which

meant that physical addresses and virtual addresses were the same. Device drivers

and BSP code could ignore the difference between virtual and physical addresses,

and the driver or BSP would still work.

1 2 ... 138 139 140 141 142 143 144 145 146 147 148 ... 188 189

Sin comentarios

RAM 6.0 BUX II Series Guía de usuario Pagina 143