02.03.2014 Views

BSP Developer's Guide

BSP Developer's Guide

BSP Developer's Guide

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

5<br />

Driver <strong>Guide</strong>lines<br />

word addresses. Thus, there are three different implementations with three<br />

different addressing schemes.<br />

Consider also that the designer who chose the long word implementation might<br />

also have chosen to require the driver to use only long word read/write accesses.<br />

The driver cannot even assume that a byte read operation can be used to read a<br />

byte register.<br />

One solution to this problem is to require that all accesses to the chip be restricted<br />

to as few routines as possible. Further, each access to the chip should be declared<br />

in a preprocessor macro that can be redefined so as to meet the special<br />

requirements of any particular system.<br />

5<br />

I/O-Mapped Chips<br />

Most engineers had their first experiences on Motorola processors that use<br />

memory mapped I/O exclusively. However, there is another world of processors<br />

using a separate address space called I/O space. Unfortunately, the C language<br />

does not provide a means to specify if an address is a memory address or an I/O<br />

address. You have to use assembly language subroutines to access the special<br />

instructions to reach data in I/O space. You cannot write a direct expression in C<br />

to do that.<br />

Fortunately, the solution to the memory-mapped problem above also solves this<br />

problem. By defining the special hardware access macros to use a special I/O<br />

subroutine, you can handle devices mapped into I/O space.<br />

Multi-Function Chips<br />

Designers are fond of combining more and more channels (devices) per chip. Then<br />

they thought up the idea for ASIC chips combining multiple devices of different<br />

types into a single piece of silicon. The designers are only limited by imagination<br />

in the ways they can combine silicon building blocks together.<br />

Rather than write a driver for a complete ASIC, you should strive to write drivers<br />

as though each subsection is a separate device. It might be necessary, if<br />

undesirable, for one driver to require support from another driver. If this is the<br />

case, then this must be clearly documented in the dependent driver<br />

documentation. A single large monolithic driver for an entire ASIC is opposed to<br />

the goal of system scalability. The user should be able to exclude features that are<br />

not needed by the application.<br />

93

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!