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

The designers of embedded hardware often prefer to use memory-mapped I/O exclusively, because it has advantages for both the hardware and software developers. It is attractive to the hardware developer because he might be able to eliminate the I/O space, and some of its associated wires, altogether. This might not significantly reduce the production cost of the board, but it might reduce the complexity of the hardware design. Memory-mapped peripherals are also better for the programmer, who is able to use pointers, data structures, and unions to interact with the peripherals more easily and efficiently. [10] The toggleLed function wouldn't have required a single line of assembly code if the P2LTCH register had been memory-mapped.

All processors store their programs and data in memory. In some cases this memory resides on the very same chip as the processor, but more often it is located in external memory chips. These chips are located in the processor's memory space, and the processor communicates with them by way of two sets of electrical wires called the address bus and the data bus. To read or write a particular location in memory, the processor first writes the desired address onto the address bus. The data is then transferred over the data bus.

As you are reading about a new board, create a table that shows the name and address range of each memory device and peripheral that is located in the memory space. Organize the table so that the lowest address is at the bottom and the highest address is at the top. Each time you add a device to the memory map, place it in its approximate location in memory and label the starting and ending addresses, in hexadecimal. After you have finished inserting all of the devices into the memory map, be sure to label any unused memory regions as such.

if you look back at the block diagram of the Arcom board in Figure 5-1, you will see that there are three devices attached to the address and data buses. These devices are the RAM and ROM and a mysterious device labeled " zilog 85230 serial controller." The documentation provided by Arcom says that the RAM is located at the bottom of memory and extends upward for the first 128 KB of the memory space. The ROM is located at the top of memory and extends downward for 256 KB. But this area of memory actually contains two ROMs-an EPROM and a Flash memory device — each of size 128 KB. The third device, the Zilog 85230 Serial Communications Controller, is a memory-mapped peripheral whose registers are accessible between the addresses 70000h and 72000h.

The memory map in Figure 5-2 shows what these devices look like to the processor. In a sense, this is the processor's "address book." Just as you maintain a list of names and addresses in your personal life, you must maintain a similar list for the processor. The memory map contains one entry for each of the memories and peripherals that are accessible from the processor's memory space. This diagram is arguably the most important piece of information about the system and should be kept up-to-date and as part of the permanent records associated with the project.

Figure 5-2. Memory map for the Arcom board

For each new board, you should create a header file that describes its most important features. This file provides an abstract interface to the hardware. In effect, it allows you to refer to the various devices on the board by name, rather than by address. This has the added benefit of making your application software more portable. If the memory map ever changes — for example, if the 128 KB of RAM is moved — you need only change the affected lines of the board-specific header file and recompile your application.

As this chapter progresses, I will show you how to create a header file for the Arcom board. The first section of this file is listed below. The part of the header file below describes the memory map. The most notable difference between the memory map in the header file and that in Figure 5-2 is the format of the addresses. Pointers Versus Addresses explains why.

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

*

* Memory Map

*

* Base Address Size Description

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

* 0000:0000h 128K SRAM

* 2000:0000h Unused

* 7000:0000h Zilog SCC Registers

* 7000:1000h Zilog SCC Interrupt Acknowledge

* 7000:2000h Unused

* C000:0000h 128K Flash

* E000:0000h 128K EPROM

*

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

#define SRAM_BASE (void *) 0x00000000

#define SCC_BASE (void *) 0x70000000

#define SCC_INTACK (void *) 0x70001000

#define FLASH_BASE (void *) 0xC0000000

#define EPROM_BASE (void *) 0xE0000000

In both C and C++, the value of a pointer is an address. So when we say that we have a pointer to some data, we really mean that we have the address at which the data is stored. But programmers don't usually set or examine these addresses directly. The exception to this rule are the developers of operating systems, device drivers, and embedded software, who sometimes need to set the value of a pointer explicitly in their code.

Unfortunately, the exact representation of an address can change from processor to processor or can even be compiler dependent. This means that a physical address like 12345h might not be stored in exactly that form, or might even be stored differently by different compilers. [11] This situation gets even more complicated if you consider the various memory models provided by some processors. All of the examples in this book assume that the 80188's large memory model is used. In this memory model all of the specifics I'm about to tell you hold for all pointer types. But in the other memory models, the format of the address stored in a pointer differs depending upon the type of code or data pointed to! The issue that then arises is how a programmer can set the value of a pointer explicitly so that it points to the desired location in the memory map.

Most C/C++ compilers for 80x86 processors use 32-bit pointers. However, the older processors don't have a simple linear 32-bit address space. For example, Intel's 80188EB processor has only a 20-bit address space. And, in addition, none of its internal registers can hold more than 16 bits. So on this processor, two 16-bit registers-a segment register and an offset register — are combined to create the 20-bit physical address. (The physical address computation involves left-shifting the contents of the segment register by four bits and adding the contents of the offset register to the result. Any overflow into the 21 st bit is ignored.)

To declare and initialize a pointer to a register located at physical address 12345h we therefore write:

int * pRegister = (int *) 0x10002345;

where the leftmost 16 bits contain the segment value and the rightmost 16 bits contain the offset value.

For convenience, 80x86 programmers sometimes write addresses as segment:offset pairs. Using this notation, the physical address 12345h would be written as 0x1000:2345 . This is precisely the value — sans colon — that we used to initialize the pointer above. However, for each possible physical address there are 4096 distinct segment:offset pairs that point to a given physical address. For example, the pairs 0x1200:0345 and 0x1234:0005 (and 4093 others) also refer to physical address 12345h.