Divide and conquer for embedded success

Embedded controllers of all sizes and capabilities are ubiquitous today, though rarely seen by consumers. Mobile handsets, for instance, contain as many as a dozen different embedded devices controlling radio transmissions, the user interface display, the keypad, even the backlight LED’s intensity. The trend is obvious: take a complex problem, divide it into several smaller, simpler, more specific problems, and apply the right tool to the right job.

This same axiom can be applied to even the most mundane embedded systems and the result is shorter design cycles, greater flexibility, and higher maintainability. The key to success is using a generally applicable communication strategy that makes remote and local functions appear seamless to the outside world.

Architectures of a similar nature comes in lots of flavors, including master-slave, host-client, hub-node, etc. But when you look closely, they’re all pretty much the same thing. From a conceptual point of view, concentrate the decision-making (the master), and distribute the action taking (the slaves).

In most complex systems, this approach is necessary and automatic. A handset, for example, has a master processor to decide what to display on the screen and what the peripherals, such as the LCD controller or radio transceiver, need to do. It’s unlikely the master processor will directly control the display’s individual pixels or the radio encoding and decoding. The master tells the display slave what to display and the display decides how; the master provides the transceiver slave the audio to encode, and the transceiver provides the audio it’s decoded.

In other embedded systems, the segmentation may not be as obvious, but the motivation and benefits are the same. If a central master can communicate with remote slaves as well as local devices, system control can be consistent across the system. For a segmented or distributed system to succeed, there must be clearly specified (and understood) interfaces. The simple fact that all cars have a gas pedal on the right and brake on the left enables us to rent a car anywhere in the world and successfully drive it off the lot.

While there are many standard communication methods available in microcontrollers (MCUs), three stand out particularly as popular in master/slave embedded systems—RS232 serial, SPI, and I2C. Slave devices that use these communication interfaces are available for purchase off-the shelf. Some lower-level device examples are analog-to-digital converters (ADCs), digital-to-analog converters (DACs), serial EEPROMs, and various types of digital I/O. Voltage sequencing and monitoring devices and closed-loop fan controllers are examples of some higher-level devices. By themselves, these devices do little or nothing. Combined in a system with a master device communicating over a standard bus, these slaves become an integral part of a larger system, and through active control from the master over the communication bus, enhanced functionality is possible.

When you survey the embedded marketplace and look at the off-the-shelf slave devices and the MCUs that could function as masters or customized slaves, one communication method stands out,—I2C, or the Inter-Integrated Circuit bus. There are two reasons for its popularity: it’s inexpensive (two wires/pins and two pull-up resistors to construct the bus), and it is easy to use. There are many individual reasons to choose a particular bus over another, but in general, I2C at 400 kHz is the best choice for a distributed embedded system.

The key benefit of divide and conquer is that simpler problems are easier to solve than complex problems. In addition, physically separating devices reduces their coupling and increases a system’s reliability. With the proper design (allocation of functions and specification of interfaces) widespread failure modes can be avoided. Finally, with experience, the division will yield more reusable design components, relieving engineers on their next project from starting from scratch.

Divide and conquer
"Divide and conquer" relies upon a communication bus, and for whatever reason, you may have a preference for choosing a bus other than I2C. But that’s okay because the strategy is bus-agnostic. A clear master/slave delineation is required, and in some cases the bus will influence some of the master/slave specifics, such as where a communication initiates. I2C is used as the bus in this example due to the prevalence of off-the-shelf devices and MCUs that support it, and because the external tools necessary to test and debug are inexpensive or easy to create.

Applying this master-slave concept in any embedded design is handled in the same way. First, you determine which decisions must be made centrally and allocate them to the host, then distribute the action to the slaves. The art is in where to draw the boundaries. One efficient strategy is: Don’t make the master wait for a slave for anything, and if a slave needs something from the master, it must call. This approach requires a third line in some cases, which is an interrupt line, so that the slave can "call" the master.

Strategy is the first step
Before commencing, you’ll need a strategy, the simpler the better. Whatever it is, your strategy must help you answer the question: Should I do X or Y? As with any similar question, there are four answers: X, Y, it doesn’t matter, and I don’t know. If your strategy frequently results in "I don’t know" answers, either your questions aren’t specific enough, or your strategy is too simple. Keep a document that captures your strategy, the questions and answers, and the resulting strategy updates (when changed), and make it available to everyone on the project at all times. This becomes a valuable when discussing schedule slips and in bringing additional people on late in the project.

Your strategy must be written down. If you write it down, everyone can work from the same strategy, you’ll be able to modify it as needed, and you can easily share it with other teams. A clear strategy followed by several groups, working together or independently, enables sharing of designs and leads to shorter design cycles and a higher confidence level.

Because the design is a system made up of several parts, some of which you may not have complete control over (such as with off-the-shelf devices), individual device constraints will enter into the equation. With experience, a clearly expressed strategy will help both in the design of the system’s custom portions and in the selection of standard devices, resulting in fewer late-stage tradeoffs and more flexibility.

Let slaves do as much work as possible and provide high-level data to the master. The goal is to have the master in an embedded system provide direction to the slaves (i.e. configure them at some point), but the measurement making, data analyzing, and action taking will, in general, be an autonomous process. Combine this with the strategy above (master never waits, slaves call only when necessary) and you can begin to see the value in distributed design. Everything does what it does best and only what’s required.

Design example
The simplest embodiment of this concept is a system that controls a piece of equipment’s front panel, consisting of buttons, switches, and LEDs. To create this front-panel design, a subsystem for a larger, more complex piece of equipment, the master will be the main processor already managing the box (likely some form of embedded Windows or Linux computer), and for the slaves, we’ll select from the dozens of I2C bus-connected I/O expander devices available off-the-shelf.

By selecting I2C bus-connected off-the-shelf I/O expanders and having the master-processor configure them at power-up, the button/switch detection inputs and LED state outputs are tied into the master processor. Any processor with an I2C bus can be the master; the configuration of buttons and LEDs can change easily, as can the specific slave devices. The devices are software configured in the master (Fig. 1).

1. In this simple master/slave system, the blue circles represent pushbutton inputs, and the red and green shapes represent LEDs.

If you already know something about these I2C I/O expander devices, the obvious question would be, "Why not use one larger device rather than two small devices?" The answer is partly a preference to isolate the input and output functions, and partly intelligent design modularization—allow changes to the input subsystem separate from the output subsystem. When the decision-making is in the master, putting a box around each function makes change to a particular function less likely to affect another function.

Using simple hardware and because all the control is in the master, change is easy. The drawback of this approach is that it’s limited in its reach. For example, what happens when you want to add an ambient light sensor that adjusts the LEDs’ brightness? The burden falls to the master to "stitch together" the slaves and accommodate all design changes, when fundamentally, the master’s view of the front panel hasn’t changed. It still just wants to know what buttons are pressed and command the LEDs to turn on and off.

Why not create custom I2C slave devices and off-load the master? This is exactly what designers should be asking right now. It’s because a custom I2C slave is employed, and it’s difficult to complete on time and on schedule. But this isn’t necessarily the case and shouldn’t be accepted as common wisdom. With a little planning and the right approach, custom slaves can deliver the goods.

If you remember our strategy, the original design fail to satisfy it in that all intelligence was contained in the master and the slaves required near-constant attention. To be fair to the off-the-shelf solutions, some specific devices address the original problem with the front-panel buttons and LEDs relatively well. But all logic gets stored in the master and all changes ripple through the master. Instead, we can define a front-panel interface and leave the details to a distributed system of slaves, requiring less interaction from the main/host processor (Fig. 2).

2. Less interaction is required from the host processor if you leave the details to a distributed system of slaves.

The question remains, how do you create the custom device without the usual pain? Use a proven I2C slave implementation that defines a stable protocol and interface, the most common protocol being the register-based one used by most off-the-shelf I2C slave devices. The details of this protocol are summarized as:

For I2C, all transactions are initiated by the master. Each slave device has an I2C 7-bit address (the least significant bit indicates whether the transaction is a read or a write). Each slave has an internal address register that maintains a pointer to an internal table of data, commands, or status. Each slave defines the addresses of its registers and their function, including whether they’re read-only or read-write. A write transaction consists of a byte with the I2C device 7-bit address and write bit, followed by a byte that sets the internal address register. If any more bytes are in the transaction, they’ll be written to the slave starting at the newly-set internal address (from the second byte). A read transaction consists of a byte with the I2C device 7-bit address and read bit, followed by the master clocking out the number of bytes from the slave that it desires, providing a stop signal when finished.

It becomes clear that the attraction of an I2C slave is that it looks like a dual-port RAM, and it is almost as easy to use. To select the programmable device (which may be a personal choice), the key factors are the ability for devices to support a wide range of needs without relearning (i.e., time-consuming learning curve issues with hardware and tools that can halt a project).

First, let’s define the push-button input slave device, creating a device with three address pins (easy upgradeability) and seven push-button inputs, configured to accept a normally open switch that closes to system power (assumed to be 5 V dc). The button states will be provided in a single byte accessible from an I2C master as described above.

Second, we define the slave device to control the LEDs, creating a device with two address pins and driving eight LEDs (at 10 mA), separated into four red and four green. A single byte called "Command" acts as the I2C command input to control the LEDs, and the lower 4 bits of this byte (lower nibble) control the red LEDs and the upper 4 bits (upper nibble) control the green LEDs.

About the author
Jon Pearson is the product manager for PSoC development tools at Cypress Semiconductor, located in Lynnwood, Wash. He can be reached at .