SLTF Consulting
Technology with Business Sense

 Home | Bio | Contact Us | Site Map


 

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 saying—borrowed 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 event—in this case an interrupt—causes 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 chips—but 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 reprogrammable—even 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



About Us | What We Do | SSM | MiCOS | Search | Designs | Articles

Copyright © 1998-2014 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.