DESIGN VIEW is the summary of the complete DESIGN SOLUTION contributed article, which begins on Page 2.
Cost is king in many embedded-system designs. To reduce costs, designers will typically call upon a single microprocessor to run the whole show, figuring that fewer parts mean lower cost. But splitting up the task among multiple processors can often simplify a design and speed its arrival to the market, more than compensating for the added cost.
However, attention must be paid to your design's characteristics to find the right solution. Keep in mind that adding a satellite processor affects system cost both positively and negatively, so the overall impact needs to be evaluated. Multiprocessing just may turn out to be the lower-cost option.
Using a satellite can lower the performance needs of the main processor, allowing for a less expensive version. It can also simplify wiring, and most importantly, it will ease development and debugging of the design. Tradeoffs must be considered, though. First, there's the cost of the additional processor. A larger potential penalty is the cost of development tools for the additional processor when it differs from the main processor.
However, smart design teams will pick a satellite processor that meets the needs of many multiprocessor designs. Thus, tool cost can be spread over many designs, lowering the overall impact. It also allows for volume purchasing of parts, yielding discounts greater than a single product run.
An actual design can illustrate best when to use multiprocessing. In this article, a state-of-the-art vending machine, which requires lots of control, is used as an example. Discussion surrounds the vending-machine controller (VMC), choosing the right serial bus for your application among the popular serial buses out there, and achieving overall simplicity in the design.
| HIGHLIGHTS: | |
| When Is It Best To Use Multiprocessing? | Software changes that come with a multiprocessor design are key in determining resultant cost benefits, as well as tradeoffs that must be made. |
| Multiprocessing Machine | One advantage of the multiprocessor vending machine is that the payment-processing task becomes independent of the other tasks. It also prevents the vending-machine controller from being tied up when waiting for payment. |
| Popular Serial Buses | Some of the more popular buses discussed are the I2C bus, the multi-drop bus (MDB), and the serial-peripheral-interconnect (SPI) bus. Also key is the RS-232 standard, a common interface on many MCUs that offers some useful features for multiprocessing. |
| Choosing A Bus | Determining which bus is best for a given multiprocessor design depends on the importance of each feature. Other key factors are the availability of devices that use the interface and conformance with standard industry practice. |
| To MDB Or Not To MDB? | "Simplicity in design" means using as few buses as possible, portending the use of MDB or I2C. For the motor-control board, MDB makes sense. But for the Internet interface, the MDB's overhead may be prohibitive. |
Full article begins on Page 2
Cost is king in many embedded-system designs. To suppress costs, designers will typically call upon a single microprocessor to run the whole show, figuring that fewer parts means lower cost. But splitting up the task among multiple processors can often simplify a design and speed its arrival to the market, more than compensating for the added cost. However, attention must be paid to your design’s characteristics to find the right solution. Keep in mind that adding a satellite processor affects system cost both positively and negatively, so the overall impact needs to be evaluated. Multiprocessing just may turn out to be the lower-cost option.
On the plus side, a satellite can lower the performance needs of the main processor. So a less-expensive version can be used. The satellite can also simplify wiring. Instead of using parallel lines for direct control, the main processor connects over a serial bus to an intelligent satellite function. Simplified wiring is typically less expensive and less likely to have noise problems.
The potentially largest plus, however, is that using a satellite processor will ease development and debugging of the design. For example, splitting functions into separate devices simplifies the software structure, making integration and debugging easier. It also allows parallel development efforts, which hasten the design process. It may even promote software reuse of satellite function hardware, accelerating follow-on designs. All of this saved time gets a product to market much quicker, which can spell the difference between market failure and success.
However, there are tradeoffs to consider. One is the cost of the additional processor, although most likely, that will be minimal because many processors are available for under a dollar in production. A larger potential penalty is the cost of development tools for the additional processor when it differs from the main processor. Smart design teams, though, will pick a satellite processor that meets the needs of many multiprocessor designs. Thus, tool cost can be spread over many designs, lowering the overall impact. It also allows volume purchasing of parts, yielding discounts greater than a single product run.
When Does Multiprocessing Make Sense? Many of these cost benefits and tradeoffs depend on the software changes that come with a multiprocessor design. To understand them, you need to look at how many different functions your design must supply. Naturally, a single-function design doesn’t benefit from a multiprocessor design approach.Most designs, however, must perform multiple functions. In such cases, the next area to examine is the concurrence of the tasks. A design could, for instance, have several functions but only perform one at a time. Consider an MP3 audio player. It must be able to play the music stored in its memory. Additionally, it must be able to accept music from an outside source and store that music in memory. Typically, though, it needn’t perform these functions concurrently and instead can focus on one task at a time. As with the single-task design, a design without concurrent tasks is also a good place to use a single processor.
One exception to this rule of thumb is that if a design’s functions are remote from the processor’s location, a multiprocessor approach might provide some benefit even if tasks aren’t concurrent. It all depends on the separation distance and the type of wiring needed.
But the best candidate for multiprocessing design is a design that must perform multiple, concurrent tasks. Typically, these tasks are independent of one another, involving separate I/O channels. Such independence allows functions to be removed from the main processor and put into a satellite.
Vending Machine Example Sometimes an actual design illustrates best when to use multiprocessing. Consider the vending machine, a device we all walk past every day. We put money in, and a product comes out. It sounds easy, but a state-of-the-art vending machine requires a lot of control. Key elements of a modern vending machine are shown in the block diagram of Figure 1. Components include:
- VMC: the vending machine controller, its main embedded processor
- Coin reader: accepts and validates coins (rejecting counterfeits) and indicates their value
- Bill reader: accepts and validates bills and indicates their value
- Card reader: for ATM or smart-card transactions
- Keypad input: reads the user’s selection
- Display output: provides the user with status information (money deposited, product cost, etc.)
- Motor and sensor control: to dispense the product, monitor inventory, run the cooling pump, monitor temperature, and scale back power usage during "off-peak" vending hours
- Maintenance port: a link that allows service personnel to interact with the machine, often with a PDA
- Internet communications: a new function that allows the machine to use the Internet to report status information and receive pricing updates from the business that owns the machine.
As technology continues to advance, other control functions will probably be added. For instance, an embedded Internet server and IrDA port would allow both online monitoring and diagnostics. Although that link would place more demands on our processing requirements, it would not affect the system during normal operation.
This embedded system must deal with concurrent, asynchronous tasks. After all, you don’t want the coin reader to be unresponsive while the machine sends information over the Internet; otherwise customers will think the machine isn’t working and walk away. Similarly, people tend to put in more coins for a second drink while the machine is delivering the first. Either way, several actions are occurring simultaneously.
Looking more closely at the embedded controller’s tasks shows that most of its time is spent waiting for someone to put in money, an event to which the system must respond immediately. Once a payment acceptance block (coin, bill, or card) is activated, the system must then focus on accepting and counting the money entered. The controller can’t be distracted by other tasks, or the machine hesitates before vending or during payment acceptance, again leading users to think that it’s not working.
The controller has to perform other time-consuming tasks as well. A controller communicating over the Internet must spend lots of time waiting for packets to arrive. Keypad reading requires a debouncing of the switches to ensure that customers don’t receive multiple drinks. Motor control for vending must ensure that the motor is active only long enough to dispense one item. All of these tasks require the processor to wait for something to finish happening so it won’t miss its completion. And that waiting may block other tasks. Such a system is a good candidate for multiprocessor design.
Multiprocessing Machine The multiprocessor vending machine has several advantages (Fig. 2). For one, the critical payment-processing task becomes independent of the remaining tasks. No matter what the VMC is doing, the machine will accept the user’s money without hesitation.
Another advantage is that this approach prevents the VMC from being tied up when waiting for payment. The satellite payment processors—bill, coin, and card—can wait for things to start happening. Only then do they handle the complex actions and sensor readings needed for validating and counting. And they perform these tasks without making an impact on any other system function. Only when payment is validated and counted does the VMC have to take action, and all it needs from the satellite processor is authorization to dispense a product. The result is simpler VMC software.
A third advantage is that the wiring needs are reduced considerably. Functions such as bill validation, for instance, require a number of control lines to sense bill insertion, run the take-up motor, detect magnetic ink, and so on. Similarly, the card reader and coin acceptor have complex signal and control requirements. The multiprocessor approach removes all of these control and signal lines from the VMC’s wiring and replaces them with a simple communications bus between the satellite processors and the VMC.
The exact nature of that communications bus is an important design decision affecting many elements of a multiprocessor design. A standard bus like I2C has the support of many intelligent peripheral devices, which may reduce the need for satellite processing. On the other hand, a proprietary protocol running on an RS-232 link lets custom satellite devices signal the main processor without it having to use a polling routine. As a result, the bus choice can dictate the range of peripherals available and the software structure of the main processor. To keep their options open, developers might want to choose a microcontroller (MCU) like the Z8 for their satellite processor, which offers a variety of bus interfaces on one chip.
Popular Serial Buses A summary of the more popular communications buses for MCUs and peripherals appears in Table 1. The table entries reflect several important criteria, including wire count, speed, and type of operation. Each bus has its strengths and limitations.The I2C bus is a low- to mid-speed master/slave link that uses two wires: data and clock. The signal is unipolar and assumes a common power and ground reference for communicating devices. As many as 127 slave devices can attach on the same wire pair. Usually, the master sends an address before every communication, with only the addressed slave responding. There’s no bus conflict, but the master must poll its slaves to get information from them. The I2C does allow the master to set up slave-to-slave communication, however, and provides bus conflict resolution for multiple-master configurations.
The multi-drop bus (MDB) is much simpler. It also follows a master/slave protocol, but can address only 32 slaves. The bus also consists of just data and clock. But it runs at a much slower speed, making it easy to implement without special hardware.
The serial-peripheral-interconnect (SPI) bus is also a master/slave protocol. However, it doesn’t start its data transmission with an address field. Instead, it uses a chip-select line for each slave device. In theory, then, an SPI master can have as many slaves as it wants. Bus signals on SPI are as fast as 1 MHz, which may require shielding on long signal runs.
The standard RS-232 is a full-duplex communications link that’s not really a bus. It only connects a given device to one other device. However, RS-232 a common interface on many MCUs, and it offers some useful features for multiprocessing. For example, it gives a satellite processor a way of signaling the main processor without waiting for its turn in the polling loop. Another is that it’s asynchronous, so there’s no clock signal running around the system. This does require a local clock source for each end, though.
Choosing A Bus Determining which bus is best for a given multiprocessor design depends on the importance of each feature. If there’s a high data-traffic requirement with few connections, SPI or RS-232 may be best. If traffic is low, the simpler MDB may be a less expensive choice.Other factors can also affect the choice. Of particular importance is the availability of devices that use the interface. The I2C, for instance, is used on a number of peripheral devices, such as sensors and displays. Utilizing a display with an I2C interface, for instance, would eliminate the need for a separate satellite display MCU.
Conformance with standard industry practice is another such factor. In these cases, the technical merits of a given bus may be moot. For example, the vending-machine industry has adopted the MDB as its standard for controlling peripheral functions. Commercially available bill readers, coin counters, and payment readers all follow the standard. So a vending-machine design must use the bus if it’s implementing prebuilt components.
But as shown in Figure 2, the MDB isn’t the only connection that must be made by the VMC. The keyboard and display, for instance, aren’t available with the MDB interface, so they must have their own. The I2C bus is an appropriate choice here, because both keyboard and display units are available off the shelf with the interface.
To MDB Or Not To MDB? "Simplicity in design" suggests that the vending machine use as few buses as possible. In this example, the vending machine already has two. Therefore, the two units that aren’t already defined—the motor-control board and the Internet interface—should consider MDB and I2C as primary candidates for their interface.For the motor-control board, the decision is relatively easy. All that’s necessary for communication exchange between the VMC and the motor-control board is a command to vend a specific product, and a status report on system temperature and stocking levels. Neither signal has critical timing, so the MDB’s limitations aren’t a factor in the decision. On the other hand, having a motor-control board design that uses MDB avoids the need for an additional communications bus and associated software. The motor-control function simply becomes another entry in the VMC’s polling loop.
The Internet connection, on the other hand, is more demanding. The MDB’s 9600-baud communications rate is adequate for Internet signaling, but the bus is shared with much slower peripherals. If they’re all on the same bus, the VMC must poll all payment units and read the motor-control status on the MDB before returning to the Internet connection. This lowers the effective bandwidth for Internet communications considerably.
The MDB overhead for communications is large. The master must send out an 11-bit word containing the address and a simple command to the peripheral. However, commands may be more than one word long. The peripheral has 5 ms to respond, then reports back with at least one 11-bit word. The master must acknowledge the response before it moves to the next poll.
As shown in Table 2, even if the polling routine uses single-word commands and responses, the polling loop takes nearly 40 ms for each peripheral. Three payment units and motor control on the bus means that the loop takes 160 ms, even when there’s no significant interaction. If the Internet link were on the same bus, the VMC would only be able to interact with it five times a second— far too slow for effective network communications.
Even though the MDB seems an unworkable choice for the Internet link, there’s a strong desire to use the bus. The solution in this example was to put the Internet connection on its own dedicated MDB. Even running as slowly as a 1-MHz clock rate, the VMC can alternate between the two buses on a clock-by-clock basis without compromising the performance of either. The dedicated MDB for the Internet link, however, offers the bus’ full transfer rate for the link. By making the Internet link conform to the MDB standard, the design becomes applicable to any vending machine built on any VMC with MDB capability. The benefits of such design reuse are compelling.
When all is said and done, the resulting vending-machine design offers adequate performance with the benefits of design simplicity. The VMC serves as a high-level controller, issuing commands and receiving status. But it doesn’t get bogged down in the details of any given function. Each major function is independent and self-contained. So they can be added, removed, and altered in their function and only make a small impact on the main program.
This is the beauty of multiprocessing design. Each element is independent and may be available off the shelf. Coordinating the activities of the diverse functions becomes a relatively simple task for the central controller. And the effects of changes to the peripherals in the design are minimized. Unless a design has only a simple task, or space constraints forbid more than one chip, the time is right for multiprocessing designs.