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.