BSP Developer's Guide

VxWorks 5.5
BSP Developer’s Guide
architecture. This chapter is a general discussion of the issues and not an
implementation-specific guide.
4.2 Architectural Considerations
At the core of any VxWorks run-time environment is the target architecture. This
section is dedicated to the capabilities and run-time ramifications of architecture
selection. Some general observations follow, but most details are covered in
sections devoted to a particular architecture.
For additional documentation that pertains to VxWorks architecture support, refer
to the following:
■
the appropriate VxWorks Architecture Supplement document
■
VxWorks API Reference: Drivers, 5.5
■
VxWorks API Reference: OS Libraries, 5.5
■
Tornado User’s Guide, 2.2
■
BSP documentation (for a target similar to yours)
■
Wind River Technical Notes, available online through WindSurf
4.2.1 Interrupt Handling
Interrupts asynchronously connect the external world to the system, and are
typically the most important aspect of real-time systems. VxWorks adopts a
vectored interrupt strategy where applications “connect” ISRs (Interrupt Service
Routines) to a unique vector generated by the interrupting component. VxWorks
provides functions to dynamically program these vectors to contain the address of
an extremely small and fast code stub that calls an application’s C-language ISR,
and then returns control to the kernel.
A frustrating complication to ordinary interrupt servicing is interrupt
acknowledgment (IACK). Most system architectures provide for automatic
interrupt acknowledgment. For the relatively few that do not address this issue,
ISRs must manually acknowledge an interrupt through a register access or by
some other awkward mechanism.
Finally, interrupt latency may vary from architecture to architecture. Interrupt
latency is the maximum amount of time from the initial processor interrupt request
64