Utilizing modularity in an embedded design opens
up a number of new possibilities when compared
to standard embedded applications. It enables
the design of compact form-factor devices,
without sacrificing functionality. Modularized embedded
designs can be designed economically, because they can
be tailored to the application—avoiding unnecessary functionality
and cost. They’re also production-friendly, since
they open up new diagnostic possibilities without requiring
excessive additional resources on the device itself.
We can better understand this modularity by examining
an embedded system comprising multiple modular
extensions that perform unique tasks. The main controller
can be programmed to act as a host that’s capable of recognizing
and controlling a number of individual, modular
plug-in cards. These cards then can perform a number of
different functions, from sensing to communications.
In generic terms, a standalone embedded-system design
comprises some of the following components: a computing
block, a sensor block, a display element, a user interface,
and some storage and connectivity options. Based on these
function blocks, we can imagine a sample application where
one or many of them are implemented modularly. To strike a
balance between computing power and cost, a good host
controller would be something like a 16- or 32-bit MCU.
As an example, we will examine a method for designing
a versatile flash card reader application. This multifunction
card reader will use flash-memory cards as the “plug-in
modules” and utilize a small 16-bit MCU as the main controller.
Cards, including Compact Flash (CF), Secure Digital
(SD), eXtreme Digital (xD), and Memory Stick, can be read
with this device. The interface requirement dictated by
these various card formats suggests that we would need
a minimum bus width of about 24 lines to guarantee compatibility
with all card types.
On the connectivity side, we would also need the card
reader to interface to a USB host, such as a PC. Note that a
number of devices from various manufacturers are designed
directly for these applications. While these are ideal when
affordable, not every design has the budget for these application-
specific chips, which are often large, high-speed ICs.
Therefore, we will examine how the application can be done
with lower-cost, general-purpose microcontrollers.
BUS FLEXIBILITY VS. PIN COST
Any embedded design can support “modular plug-ins,” if it
uses enough pins. Designers can tie pins of various peripherals
from the controller together to obtain a bus with the necessary
functionality. There’s a logical progression covering
pins used and functionality obtained—using only two pins,
designers can’t do much except provide power and ground
to the plug-in card. Although these two pins needn’t come off
the MCU, they can be brought out from the MCU if necessary
to provide more control over the power to the card.
A bus with four I/O signals can assist designers in implementing
a number of functions. These functions include a
variety of serial communications, analog-to-digital conversion,
and others. By using a six-line I/O bus, you will be able
to address all types of serial communication requirements. (A
parallel communication interface requires 10 lines or more.)
Using regular MCUs with fixed I/O pinouts, the schematics
of this design may reveal that many of the peripherals needed
for the card reader can actually be found multiplexed on the
same pins of the MCU. While this sounds ideal, it’s more than
likely that the multiplexing combination will not match the
plug-in card pinout. Also, these I/O pins may be on an inconvenient
side of the MCU, resulting in PCB routing problems.
One way to get around this problem is to use an expensive,
high-pin-count MCU that’s rich in I/O lines, and thus
there are no I/O placement restrictions (Fig. 1). However, you
will be left with quite a few unused pins on a large-packaged
MCU, which means wasted space and excess cost.
The other alternative is to use
a compact MCU with fewer I/O
pins, which uses a few multiplexers
and glue logic to get
the required bus width of 24
signal lines with the appropriate
functionality (Fig. 2). Under
this approach, the compact
form factor of the design is the
first casualty. Routing, carddetection
logic, and firmware
will also become complicated.
Designers have yet another
option to handle this tangled
I/O line problem. They can
cluster the required I/O lines
and implement the peripherals in software—
SPI or UART functions can be
bit-banged through I/O pins. This avoids
the higher system costs from either the
usage of a high-pin-count MCU or extra
devices. Beware, though—when these
peripheral functions are mimicked in
software, the MCU performance may
degrade or the design may dissipate
more power due to faster CPU operation.
As a result, you can still end up with
a costly, complicated design.
Depending on the application (type of
card inserted and detected), bootloading
the code into the MCU can work well.
This is accomplished by putting a small
amount of flash memory, which has the
new code, on the plug-in module itself or
on a separate loader card. Other applications
will require all or most of the cardhandling
code to be already present in
the MCU. This will allow for the smallest
and cheapest possible plug-in cards, at
the cost of using more flash memory
on the MCU.
Continue on Page 2