The final type of processor is a digital signal processor, or DSP. The CPU within a DSP is specially designed to perform discrete-time signal processing calculations like those required for audio and video communications extremely fast. Because DSPs can perform these types of calculations much faster than other processors, they offer a powerful, low-cost microprocessor alternative for designers of modems and other telecommunications and multimedia equipment. Two of the most common DSP families are the TMS320Cxx and 5600x series from TI and Motorola, respectively.
5.4.2 Intel's 80188EB Processor
Although the on-chip peripherals are distinct hardware devices, they act like little extensions of the 80186 CPU. The software can control
them by reading and writing a 256-byte block of registers known as the peripheral control block (PCB). you may recall that we encountered this block when we first discussed the memory and I/O maps for the board. By default the PCB is located in the I/O space, beginning at address FF00h. However, if so desired, the PCB can be relocated to any convenient address in either the I/O or memory space.
The control and status registers for each of the on-chip peripherals are located at fixed offsets from the PCB base address. The exact offset of each register can be found in a table in the 80188EB Microprocessor User's Manual. To isolate these details from your application software, it is good practice to include the offsets of any registers you will be using in the header file for your board. I have done this for the Arcom board, but only those registers that will be discussed in later chapters of the book are shown here:
/**********************************************************************
*
* On-Chip Peripherals
*
**********************************************************************/
/*
* Interrupt Control Unit
*/
#define EOI (PCB_BASE + 0x02)
#define POLL (PCB_BASE + 0x04)
#define POLLSTS (PCB_BASE + 0x06)
#define IMASK (PCB_BASE + 0x08)
#define PRIMSK (PCB_BASE + 0x0A)
#define INSERV (PCB_BASE + 0x0C)
#define REQST (PCB_BASE + 0x0E)
#define INSTS (PCB_BASE + 0x10)
/*
* Timer/Counters
*/
#define TCUCON (PCB_BASE + 0x12)
#define T0CNT (PCB_BASE + 0x30)
#define T0CMPA (PCB_BASE + 0x32)
#define T0CMPB (PCB_BASE + 0x34)
#define T0CON (PCB_BASE + 0x36)
#define T1CNT (PCB_BASE + 0x38)
#define T1CMPA (PCB_BASE + 0x3A)
#define T1CMPB (PCB_BASE + 0x3C)
#define T1CON (PCB_BASE + 0x3E)
#define T2CNT (PCB_BASE + 0x40)
#define T2CMPA (PCB_BASE + 0x42)
#define T2CON (PCB_BASE + 0x46)
/*
* Programmable I/O Ports
*/
#define P1DIR (PCB_BASE + 0x50)
#define P1PIN (PCB_BASE + 0x52)
#define P1CON (PCB_BASE + 0x54)
#define P1LTCH (PCB_BASE + 0x56)
#define P2DIR (PCB_BASE + 0x58)
#define P2PIN (PCB_BASE + 0x5A)
#define P2CON (PCB_BASE + 0x5C)
#define P2LTCH (PCB_BASE + 0x5E)
Other things you'll want to learn about the processor from its databook are:
Where should the interrupt vector table be located? Does it have to be located at a specific address in memory? If not, how does the processor know where to find it?
What is the format of the interrupt vector table? Is it just a table of pointers to ISR functions?
Are there any special interrupts, sometimes called traps, that are generated within the processor itself? Must an ISR be written to handle each of these?
How are interrupts enabled and disabled (globally and individually)?
How are interrupts acknowledged or cleared?
5.5 Study the External Peripherals
Begin by making a list of the external peripherals. Depending on your application, this list might include LCD or keyboard controllers, A/D converters, network interface chips, or custom ASICs (Application-Specific Generated Circuits). In the case of the Arcom board, the list contains just three items: the Zilog 85230 Serial Controller, parallel port, and debugger port.
You should obtain a copy of the user's manual or databook for each device on your list. At this early stage of the project, your goal in reading these documents is to understand the basic functions of the device. What does the device do? What registers are used to issue commands and receive the results? What do the various bits and larger fields within these registers mean? When, if ever, does the device generate interrupts? How are interrupts acknowledged or cleared at the device?
When you are designing the embedded software, you should try to break the program down along device lines. It is usually a good idea to associate a software module called a device driver with each of the external peripherals. This is nothing more than a collection of software routines that control the operation of the peripheral and isolate the application software from
the details of that particular hardware device. I'll have a lot more to say about device drivers in Chapter 7.
5.6 Initialize the Hardware
If you are one of the first software engineers to work with a new board especially a prototype the hardware might not work as advertised. All processor-based boards require some amount of software testing to confirm the correctness of the hardware design and the proper functioning of the various peripherals. This puts you in an awkward position when something is not working properly. How do you know if the hardware or your software is to blame? If you happen to be good with hardware or have access to a simulator, you might be able to construct some experiments to answer this question. Otherwise, you should probably ask a hardware engineer to join you in the lab for a joint debugging session.