Michael Barr - Programming Embedded Systems in C and C++

If a separate I/O space is present, it will be necessary to repeat the memory map exercise to create an I/O map for the board as well. The process is exactly the same. Simply create a table of peripheral names and address ranges, organized in such a way that the lowest addresses are at the bottom. Typically, a large percentage of the I/O space will be unused because most of the peripherals located there will have only a handful of registers.

The I/O map for the arcom board is shown in Figure 5-3. It includes three devices: the peripheral control block (PCB), parallel port, and debugger port. The PCB is a set of registers within the 80188EB that are used to control the on-chip peripherals. The chips that control the parallel port and debugger port reside outside of the processor. These ports are used to communicate with the printer and a host-based debugger, respectively.

Figure 5-3. I/O map for the Arcom board

The I/O map is also useful when creating the header file for your board. each region of the I/O space maps directly to a constant, called the base address. The translation of the above I/O map into a set of constants can be found in the following listing:

/**********************************************************************

*

* I/O Map

*

* Base Address Description

* --------------- ----------------------------------------

* 0000h Unused

* FC00h SourceVIEW Debugger Port (SVIEW)

* FD00h Parallel I/O Port (PIO)

* FE00h Unused

* FF00h Peripheral Control Block (PCB)

*

**********************************************************************/

#define SVIEW_BASE 0xFC00

#define PIO_BASE 0xFD00

#define PCB_BASE 0xFF00

Now that you know the names and addresses of the memory and peripherals attached to the processor, it is time to learn how to communicate with the latter. There are two basic communication techniques: polling and interrupts. In either case, the processor usually issues some sort of commands to the device — by way of the memory or I/O space — and waits for the device to complete the assigned task. For example, the processor might ask a timer to count down from 1000 to 0. Once the countdown begins, the processor is interested in just one thing: is the timer finished counting yet?

If polling is used, then the processor repeatedly checks to see if the task has been completed. This is analogous to the small child who repeatedly asks "are we there yet?" throughout a long trip. Like the child, the processor spends a large amount of otherwise useful time asking the question and getting a negative response. To implement polling in software, you need only create a loop that reads the status register of the device in question. Here is an example:

do {

// Play games, read, listen to music, etc.

…

// Poll to see if we're there yet.

status = areWeThereYet();

} while (status == NO);

The second communication technique uses interrupts. An interrupt is an asynchronous electrical signal from a peripheral to the processor. When interrupts are used, the processor issues commands to the peripheral exactly as before, but then waits for an interrupt to signal completion of the assigned work. While the processor is waiting for the interrupt to arrive, it is free to continue working on other things. When the interrupt signal is finally asserted, the processor temporarily sets aside its current work and executes a small piece of software called the interrupt service routine (isr). When the ISR completes, the processor returns to the work that was interrupted.

Of course, this isn't all automatic. The programmer must write the ISR himself and "install" and enable it so that it will be executed when the relevant interrupt occurs. The first few times you do this, it will be a significant challenge. But, even so, the use of interrupts generally decreases the complexity of one's overall code by giving it a better structure. Rather than device polling being embedded within an unrelated part of the program, the two pieces of code remain appropriately separate.

On the whole, interrupts are a much more efficient use of the processor than polling. The processor is able to use a larger percentage of its waiting time to perform useful work. However, there is some overhead associated with each interrupt. It takes a good bit of time-relative to the length of time it takes to execute an opcode — to put aside the processor's current work and transfer control to the interrupt service routine. Many of the processor's registers must be saved in memory, and lower-priority interrupts must be disabled. So in practice both methods are used frequently. Interrupts are used when efficiency is paramount or multiple devices must be monitored simultaneously. Polling is used when the processor must respond to some event more quickly than is possible using interrupts.

Most embedded systems have only a handful of interrupts. Associated with each of these are an interrupt pin (on the outside of the processor chip) and an ISR. In order for the processor to execute the correct ISR, a mapping must exist between interrupt pins and ISRs. This mapping usually takes the form of an interrupt vector table. The vector table is usually just an array of pointers to functions, located at some known memory address. The processor uses the interrupt type (a unique number associated with each interrupt pin) as its index into this array. The value stored at that location in the vector table is usually just the address of the ISR to be executed. [12] A few processors actually have the first few instructions of the ISR stored there, rather than a pointer to the routine.

It is important to initialize the interrupt vector table correctly. (If it is done incorrectly, the ISR might be executed in response to the wrong interrupt or never executed at all.) The first part of this process is to create an interrupt map that organizes the relevant information. An interrupt map is a table that contains a list of interrupt types and the devices to which they refer. This information should be included in the documentation provided with the board. Table 5-1 shows the interrupt map for the arcom board.

Table 5-1. Interrupt Map for the Arcom Board

Once again, our goal is to translate the information in the table into a form that is useful for the programmer. After constructing an interrupt map like the one above, you should add a third section to the board-specific header file. Each line of the interrupt map becomes a single #define within the file, as shown:

/**********************************************************************

*

* Interrupt Map

*

**********************************************************************/

/*

* Zilog 85230 SCC

*/

#define SCC_INT 17

/*

* On-Chip Timer/Counters

*/

#define TIMER0_INT 8