Single-board microcontroller

Internal bus

The bus of the early single-board devices, such as the Z80 and 6502, was universally a Von Neumann architecture. Program and data memory were accessed via the same shared bus, even though they were stored in fundamentally different types of memory: ROM for programs and RAM for data. This bus architecture was needed to economise the number of pins needed from the limited 40 available for the processor's ubiquitous dual-in-line IC package.

It was common to offer access to the internal bus through an expansion connector, or at least provide space for a connector to be soldered on. This was a low-cost option and offered the potential for expansion, even if it was rarely used. Typical expansions would be I/O devices or additional memory. It was unusual to add peripheral devices such as tape or disk storage, or a CRT display

Later, when single-chip microcontrollers, such as the 8048, became available, the bus no longer needed to be exposed outside the package, as all necessary memory could be provided within the chip package. This generation of processors used a Harvard architecture with separate program and data buses, both internal to the chip. Many of these processors used a modified Harvard architecture, where some write access was possible to the program data space, thus permitting in-circuit programming. None of these processors required, or supported, a Harvard bus across a single-board microcontroller. When they supported a bus for expansion of peripherals, a dedicated I/O bus, such as I²C, 1-Wire or various serial buses, was used.

External bus expansion

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 provides resources not already present on the single board system. Since not every system will require expansion, the connector may be optional, with a mounting position provided for installation by the user if desired.

Input and output

Microcontroller systems provide multiple forms of input and output signals to allow application software to control an external "real-world" system. Discrete digital I/O provides a single bit of data (on or off). Analog signals, representing a continuous variable range, such as temperature or pressure, can also be inputs and outputs for microcontrollers.

Discrete digital inputs and outputs might be buffered from the microprocessor data bus only by an addressable latch, or might be operated by a specialized input/output IC, such as an Intel 8255 or Motorola 6821 parallel input/output adapter. Later single-chip microcontrollers have input and output pins available. These input/output circuits usually do not provide enough current to directly operate devices like lamps or motors, so solid-state relays are operated by the microcontroller digital outputs, and inputs are isolated by signal conditioning level-shifting and protection circuits.

One or more analog inputs, with an analog multiplexer and common analog-to-digital converter, are found on some microcontroller boards. Analog outputs may use a digital-to-analog converter or, on some microcontrollers, may be controlled by pulse-width modulation. For discrete inputs, external circuits may be required to scale inputs, or to provide functions like bridge excitation or cold junction compensation.

To control component costs, many boards were designed with extra hardware interface circuits but without the components for these circuits installed, leaving the board bare. The circuit was 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 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 include a pluggable, re-usable breadboard for easy prototyping of extra I/O circuits that could be changed or removed for later projects.

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 networks (Wi-Fi, Zigbee, or others), or provide an Ethernet connection. In addition, they may support a TCP/IP protocol stack. Some devices have firmware available to implement a Web server, allowing an application developer to rapidly build a Web-enabled instrument or system.

Programming

Many early systems had no internal facilities for programming, and relied on a separate "host" system for this task. This programming was typically done in assembly language, or sometimes in C or PL/M, and then cross-assembled or cross-compiled on the host. Some single-board microcontrollers support a BASIC language system, allowing programs to be developed on the target hardware. Hosted development allows all the storage and peripherals of a desktop computer to be used, providing a more powerful development environment.

EPROM burning

Early microcontrollers relied on erasable programmable read-only memory (EPROM) devices to hold the application program. The object code from a host system would be "burned" onto an EPROM with an EPROM programmer. This EPROM was then physically plugged into the board. As the EPROM would be removed and replaced many times during program development, it was common to provide a ZIF socket to avoid wear or damage. Erasing an EPROM with a UV eraser takes a considerable time, and so it was also common for a developer to have several EPROMs in circulation at any one time.

Some microcontroller devices were available with on-board EPROM. These would also be programmed in a separate burner, then put into a socket on the target system.

The use of EPROM sockets allowed field updates to the application program, either to fix errors or to provide updated features.

Keypad monitors

When the single-board controller formed the entire development environment (typically in education), the board might also have included 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 often assembled by hand on paper before being inputted. It is arguable as to which process was more time-consuming and error prone: assembling by hand, or keying byte-by-byte.

Single-board "keypad and calculator display" microcontrollers of this type were very similar to some low-end microcomputers of the time, such as the KIM-1 or the Microprofessor I. Some of these microprocessor "trainer" systems are still in production today, used as very low-cost introductions to microprocessors at the hardware programming level.

Hosted development

When desktop personal computers appeared, initially CP/M or Apple II, then later the IBM PC and compatibles, there was a shift to hosted development. Hardware was now cheaper and RAM capacity had expanded such that it was possible to download the program through the serial port and hold it in RAM. This massive reduction in the cycle time to test a new version of a program gave an equally large boost in development speed.

This program memory was still volatile and would be lost if power was lost. Flash memory was not yet available at a viable price. As a completed controller project was usually required to be non-volatile, the final step in a project was often to burn it to an EPROM.

Single-chip microcontrollers

Single-chip microcontrollers, such as the Intel 8748, combined many of the features of previous boards into a single IC package. Single-chip microcontrollers integrate memory (both RAM and ROM) on-package and, therefore, do not need to expose the data and address bus through the pins of the IC package. These pins are then available for I/O lines. These changes also reduce the area required on the printed circuit board and simplify the design of the single-board microcontroller. Examples of single-chip microcontrollers include:

• Intel 8748
• PIC
• Atmel AVR

Program memory

For production use as embedded systems, the on-board ROM was either mask programmed at the chip factory or one-time programmed (OTP) by the developer as a PROM. PROMs often used the same UV EPROM technology for the chip, but in a cheaper package without the transparent erasure window. During program development, it was still necessary to burn EPROMs. In this case, the entire controller IC, and therefore the ZIF sockets, would be provided.

With the development of affordable EEPROM and flash memory, it became practical to attach the controller permanently to the board and to download program code from a host computer through a serial connection. This was termed "in-circuit programming". Erasure of old programs was carried out by either over-writing them with a new download, or bulk erasing them electrically (for EEPROM). The latter method was slower, but could be carried out in-situ.

The main function of the controller board was then to carry the support circuits for this serial or, on later boards, USB interface. As a further convenience during development, many boards also had low-cost features like LED monitors of the I/O lines or reset switches mounted on board.

Single-board microcontrollers today

It is now cheap and simple to design circuit boards for microcontrollers. Development host systems are also cheap, especially when using open source software. Higher level programming languages abstract details of the hardware, making differences between specific processors less obvious to the application programmer. Rewritable flash memory has replaced slow programming cycles, at least during program development. Accordingly, almost all development now is based on cross-compilation from personal computers and programs are downloaded to the controller board through a serial-like interface, usually appearing to the host as a USB device.

The original market demand for a simplified board implementation is no longer as relevant for microcontrollers. Single-board microcontrollers are still important, but have shifted their focus to:

• Easily accessible platforms aimed at traditionally "non-programmer" groups, such as artists, designers, hobbyists, and others interested in creating interactive objects or environments. Some typical projects in 2011 included: the backup control of DMX stage lights and special effects, multi-camera control, autonomous fighting robots, controlling bluetooth projects from a computer or smart phone, LEDs and multiplexing, displays, audio, motors, mechanics, and power control. These controllers may be embedded to form part of a physical computing project. Popular choices for this work are the Arduino, Dwengo or Wiring.
• Technology demonstration boards for innovative processors or peripheral features:
  • AVR Butterfly
  • Parallax Propeller