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

A Flash driver for the amd 29f010 device on the arcom board is shown below. This driver contains just two functions: flashErase and flashWrite . These functions erase an entire sector and write an array of bytes, respectively. You should be able to see from the code listings that the interaction with the Flash device is no picnic. This code will work only with an AMD 29F010 device. However, the same API could be used with any Flash memory device.

#include "tgt188eb.h"

/*

* Features of the AMD 29F010 Flash memory device.

*/

#define FLASH_SIZE 0x20000

#define FLASH_BLOCK_SIZE 0x04000

#define UNLOCK1_OFFSET 0x5555

#define UNLOCK2_OFFSET 0x2AAA

#define COMMAND_OFFSET 0x5555

#define FLASH_CMD_UNLOCK1 0xAA

#define FLASH_CMD_UNLOCK2 0x55

#define FLASH_CMD_READ_RESET 0xF0

#define FLASH_CMD_AUTOSELECT 0x90

#define FLASH_CMD_BYTE_PROGRAM 0xA0

#define FLASH_CMD_ERASE_SETUP 0x80

#define FLASH_CMD_CHIP_ERASE 0x10

#define FLASH_CMD_SECTOR_ERASE 0x30

#define DQ7 0x80

#define DQ5 0x20

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

*

* Function: flashWrite()

*

* Description: Write data to consecutive locations in the Flash.

*

* Notes: This function is specific to the AMD 29F010 Flash

* memory. In that device, a byte that has been

* previously written must be erased before it can be

* rewritten successfully.

*

* Returns: The number of bytes successfully written.

*

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

int flashWrite(unsigned char* baseAddress, const unsigned char data[], unsigned int nBytes) {

unsigned char * flashBase = FLASH_BASE;

unsigned int offset;

for (offset = 0; offset < nBytes; offset++) {

/*

* Issue the command sequence for byte program.

*/

flashBase[UNLOCK1_OFFSET] = FLASH_CMD_UNLOCK1;

flashBase[UNLOCK2_OFFSET] = FLASH_CMD_UNLOCK2;

flashBase[COMMAND_OFFSET] = FLASH_CMD_BYTE_PROGRAM;

/*

* Perform the actual write operation.

*/

baseAddress[offset] = data[offset];

/*

* Wait for the operation to complete or time-out.

*/

while (((baseAddress[offset] & DQ7) != (data[offset] & DQ7)) && !(baseAddress[offset] & DQ5));

if ((baseAddress[offset] & DQ7) != (data[offset] & DQ7)) {

break;

}

}

return (offset);

} /* flashWrite() */

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

*

* Function: flashErase()

*

* Description: Erase a block of the Flash memory device.

*

* Notes: This function is specific to the AMD 29F010 Flash

* memory. In this device, individual sectors may be

* hardware protected. If this algorithm encounters

* a protected sector, the erase operation will fail

* without notice.

*

* Returns: O on success.

* Otherwise -1 indicates failure.

*

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

int flashErase(unsigned char * sectorAddress) {

unsigned char * flashBase = FLASH_BASE;

/*

* Issue the command sequence for sector erase.

*/

flashBase[UNLOCK1_OFFSET] = FLASH_CMD_UNLOCK1;

flashBase[UNLOCK2_OFFSET] = FLASH_CMD_UNLOCK2;

flashBase[COMMAND_OFFSET] = FLASH_CMD_ERASE_SETUP;

flashBase[UNLOCK1_OFFSET] = FLASH_CMD_UNLOCK1;

flashBase[UNLOCK2_OFFSET] = FLASH_CMD_UNLOCK2;

*sectorAddress = FLASH_CMD_SECTOR_ERASE;

/*

* Wait for the operation to complete or time-out.

*/

while (!(*sectorAddress & DQ7) && !(*sectorAddress & DQ5));

if (!(*sectorAddress & DQ7)) {

return (-1);

}

return (0);

} /* flashErase() */

Of course, this is just one possible way to interface to a Flash memory — and not a particularly advanced one at that. In particular, this implementation does not handle any of the chip's possible errors. What if the erase operation never completes? The function flashErase will just keep spinning its wheels, waiting for that to occur. A more robust implementation would use a software time-out as a backup. For example, if the Flash device doesn't respond within twice the maximum expected time (as stated in the databook), the routine could stop polling and indicate the error to the caller (or user) in some way.

Another thing that people sometimes do with Flash memory is to implement a small filesystem. because the flash memory provides nonvolatile storage that is also rewriteable, it can be thought of as similar to any other secondary storage system, such as a hard drive. In the filesystem case, the functions provided by the driver would be more file-oriented. Standard filesystem functions like open , close , read , and write provide a good starting point for the driver's programming interface. The underlying filesystem structure can be as simple or complex as your system requires. However, a well-understood format like the File Allocation Table (FAT) structure used by DOS is good enough for most embedded projects.

In addition to the processor and memory, most embedded systems contain a handful of other hardware devices. Some of these devices are specific to the application domain, while others — like timers and serial ports — are useful in a wide variety of systems. The most generically useful of these are often included within the same chip as the processor and are called internal, or on-chip, peripherals. Hardware devices that reside outside the processor chip are, therefore, said to be external peripherals. In this chapter we'll discuss the most common software issues that arise when interfacing to a peripheral of either type.

The basic interface between an embedded processor and a peripheral device is a set of control and status registers. These registers are part of the peripheral hardware, and their locations, size, and individual meanings are features of the peripheral. For example, the registers within a serial controller are very different from those in a timer/counter. In this section, I'll describe how to manipulate the contents of these control and status registers directly from your C/C++ programs.