Page 111 - DCAP210_INTRODUCTION__TO_MICROPROCESSORS

Unit 7: Memory Interfacing

To control component costs, many boards were designed with extra hardware interface circuits Notes
but the components for these circuits weren’t installed and the board was left bare. The circuit
was only added as an option on delivery, or could be populated later.
It is common practice for boards to include “prototyping areas”, areas of the board already laid
out as a solderable breadboard area with the bus and power rails available, but without a defined
circuit. Several controllers, particularly those intended for training, also included a pluggable re-
usable breadboard for easy prototyping of extra I/O circuits that could be changed or removed
for later projects.

7.4.3 Bus

Some microcontroller boards using a general-purpose microprocessor can bring the address and
data bus of the processor to an expansion connector, allowing additional memory or peripherals
to be added. This would provide resources not already present on the single board system. Since
not all systems require expansion, the connector may be an option, with a mounting position
provided for the connector for installation by the user if desired.

7.4.4 Communications and User Interfaces

Communications interfaces vary depending on the age of the microcontroller system. Early systems
might implement a serial port] to provide RS_232 or current loop. The serial port could be used
by the application program, or could be used, in conjunction with a monitor ROM, to transfer
programs into the microcontroller memory. Current microcontrollers may support USB, wireless
network ports, or provide an Ethernet connection. Some devices have firmware available to
implement a Web server, allowing an application developer to rapidly build a Web-enable
instrument or system.

7.4.5 Programming
Many of the earliest systems had no internal facility for programming at all, and relied on a
separate “host” system. This programming was typically in assembly language, sometimes C or
even PL/M, and then cross-assembled or cross-compiled on the host.

7.4.6 EPROM Burning

The completed object code from the host system (usually in Intel HEX format) would then be
“burned” onto an EPROM with an EPROM programmer, this EPROM then being physically
plugged into the board. As the EPROM would be removed and replaced many times during
program development, it was usual to provide a ZIF socket to avoid wear or damage. As “washing”
an EPROM with a UV eraser takes a considerable time, it was also usual for a developer to have
several EPROMs in circulation at any one time.

7.4.7 Keypad Monitors

Where the single-board controller formed the entire development environment (typically in
education) the board might also be provided with a simple hexadecimal keypad, calculator-style
LED display and a “monitor” program set permanently in ROM. This monitor allowed machine
code programs to be entered directly through the keyboard and held in RAM. These programs
were in machine code, not even in assembly language, and were assembled by hand on paper
first. It’s arguable as to which process was more time-consuming and error prone: assembling by
hand, or keying byte-by-byte.

LOVELY PROFESSIONAL UNIVERSITY 105