Checkout lower performance processors, too
Scott Rosenthal
January, 1993
When starting design on a new project you can quickly be come inundated with marketing
hype. "Faster, faster, faster!" scream the press releases. "More MIPs! More
features! More pins!" cry out chip manufacturers. In the end you begin to feel that
you're somehow technically negligent if you don't squeeze at least a few high-speed,
next-generation gizmos into your embedded design. However, at my office I have a
sayingborrowed from another milieu but still applicable"Speed
kills." Although new technology can be fun to play with and speed is great, finesse
is always better. In this vein, I've been searching for solutions other than faster CPUs
for my applications. I believe that 4- and 8-bit processors can increase an overworked
CPU's efficiency by taking over some of its tasks. Just as a successful manager is the
person who effectively delegates, a CPU becomes much more effective when you distribute
tasks to other processors. In addition, because the central processor is doing less,
getting by with a less-powerful chip is possible. Of course, the bottom line is what
counts, and the less powerful the computer, the lower its cost and therefore the lower the
end-system's cost.
Speed = $$$
To see how CPU speed can impact a project's economics, consider that you typically
design a processor into an embedded system based on the application's fastest processing
requirements. Unfortunately, you can't buy a computer to occasionally run five times
faster without also designing all support chips, power supplies and circuit board for this
maximum speed. The faster the system, the more the parts cost and the more power the
system uses. As an alternative, take a lesson from the software side and think in terms of
a multitasking system. A task typically performs one function in a program, running either
periodically or in response to some external event. A simple example is the real-time
clock within a PC. Approximately every 55 msec an external eventin this case an
interruptcauses the PC timekeeping task to run, which updates the time-of-day clock.
Because this task's only purpose is to keep track of time, you could in theory assign it
to a second processor to ease the processing burden on the main one. The secrets to
implementing this technique are finding the performance bottlenecks in an embedded program
and a way (in terms of dollars and PC-board real estate) of moving bottleneck tasks onto
separate processors at the least expense.
I'm not advocating true parallel processing in an embedded system, but rather that you
should create functional subsystems by assigning a specific function or task to a slave
processor so that it reduces the complexity of the process the CPU must manage. The PC
world is again a place to find a simple example of this approach. The keyboard contains a
processor such as an 8042 whose sole purpose is to translate keystrokes into information
the main processor can understand. This division of labor allows the main processor to
ignore problems such as contact bounce, multiple key hits and key rollover because the
slave processor has already dealt with them. And while you do incur costs for this
technique, examples abound in terms of very low-cost items such as processors.
47¢ computers
In determining the cost of secondary processors, the first thing to remember is that
computers cost money. For example, I did a paper design for a dual-temperature monitor,
but in the quantities the client wanted the parts cost approximately $100/unit. The client
told me he didn't understand why the design cost so much if he can go to any drugstore and
buy a digital fever thermometer for $6! I tried to explain quantity purchasing, masked
ROMs and custom chipsbut he still didn't buy my arguments. However, this episode did
get me looking into low-cost microprocessors. As a part of the research I bought a cheap
fever thermometer, took it apart and discovered it was using a 4-bit microcomputer costing
47¢ in quantities of 10,000. Imagine, a computer for less than my eight year old's
allowance.
Although most of you don't design for such high volumes, there is still something to
learn from this example: additional bits of databus width cost money, so use only what is
needed. However, in reality most low-cost processors are custom devices with programs
permanently encoded within their ROMs. Most chip manufacturers won't discuss masked ROMs
unless the volume exceeds 5000 pieces. In addition, my clients are always adding new
features to their products, so masked ROMs aren't a viable choice.
During the past year, I've been investigating low-cost, single-chip computers for two
reasons: to offload work from a main processor and to design low-cost instruments
analogous to the previously mentioned temperature monitor. These two applications are
similar because both require low cost, easy implementation and on-chip program memory that
you can program at the workbench. These parts must also be easy to use, need few external
components, be easy to connect to other processors and cost roughly $10 or less in
quantities of 100.
While searching for parts meeting these requirements, I have identified the
manufacturers in the nearby table. Some offer 4-bit processors, others 8-bit parts and
some produce both. The one item each offers is One Time Programmable (OTP) versions of
their microcomputers. On these parts, the chip's internal memory is identical to the
familiar UV-erasable memories used in UVEPROMs, but the devices don't have a window
through which to erase them. Thus chip vendors can use an inexpensive plastic package
instead of an expensive ceramic one. Although you can't change the program in the chip, I
don't consider this limitation a problem because after debugging the software for these
components their function shouldn't change down the road. If the function does change, the
part is cheap enough to throw it away and replace it. Some manufacturers will soon market
flash-memory versions of their microcomputers. These chips will be
reprogrammableeven when they're soldered into a circuit board.
Just as a PLD allows a hardware designer to customize a circuit function, these
low-cost computers should allow you to craft higher-level functional blocks. For example,
a lot of the instruments we design use LEDs as a quantitative light source, that is, as a
lamp in a spectrophotometric measurement. Over the years we've gained tremendous knowledge
about how to control these lamps. For example, we pulse the LEDs to get more light out of
them. However, the way we pulse the LEDs is crucial to the instrument's success, and it
typically must time the duty cycle and A/D conversions to within a few microseconds. This
cycling must also happen continuously, without fail, to keep the LEDs from failing.
Instead of burdening a main processor with this demanding task, we now use a separate
low-cost device. When this LED driver processor has information for the system CPU, it
signals that processor by asserting an interrupt. Now the main processor isn't as busy,
and instead we often can use a less-powerful chip.
A significant consideration in implementing functional blocks in this way is how these
different computers communicate with each other. Again, simplicity is the key word. One
technique is to use a simple serial bus, I2C from Signetics and National Semiconductor's
Microwire are two common examples. You can implement these interfaces either through
dedicated on-chip hardware or through software. They don't move data fast, but speed isn't
the issue here. A clever designer can program a simple bootstrap program into the low-cost
processor, and that code's only purpose is to download a program from the main processor
into executable RAM. This way you can change the programs for each low-cost processor by
just modifying memory in the main processor. And if the main processor uses flash memory
and a PCMCIA memory-card connector, you have a system able to be modified in a few
seconds. PE&IN
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|