Embedded controllers of all sizes and capabilities are ubiquitous today, though rarely seen by consumers. Cell phones, for instance, contain as many as a dozen different embedded devices controlling everything from radio transmissions, the user interface display, the keypad, even the intensity of the backlight LED. 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 system 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.

Master-Slave, Host-Client, Hub-Node: It all means the same thing

 (Fig.1)

Whatever you call it, the concept comes down to the same thing: concentrate the decision-making (this is the master), and distribute the action taking (these are the slaves). In most complex systems, this approach is necessary and automatic. A cell phone, for example, has a master processor to decide what to display on the screen and what peripherals, such as the LCD display controller or radio transceiver, need to do. It is extremely unlikely the master processor will directly control the individual pixels of the display or the radio encoding and decoding. The master tells the display slave device 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 has 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 slave devices as well as local devices, system control can be consistent across the system. For a segmented or distributed system to succeed, there needs to 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 (after that, local traffic patterns and the ability to read the signage may start to present a problem).

While there are many standard communication methods available in microcontrollers, 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 (ADC), digital-to-analog converters (DAC), 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 via active control from the master over the communication bus, enhanced functionality is possible.

I2C – The Unofficial de facto Embedded Standard

When you survey the embedded marketplace, and look at the offerings of off-the-shelf slave devices and the microcontrollers that could be used as master devices or customized slaves, one communication method stands out – I2C, or the Inter-Integrated Circuit bus. There are two reasons for its popularity: it is 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 400KHz 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. Additionally, physically separating devices reduces their coupling and increases the reliability of a system. With the proper design (allocation of functions and specification of interfaces) widespread failure modes can be avoided. Finally, with experience, the division will yield many more reusable design components, relieving engineers on their next project from starting from scratch (or even better, allowing the next project to concentrate on improvements).

Divide and Conquer Do-It-Yourself Guide

“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 OK 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 because of the prevalence of off-the-shelf devices and microcontrollers 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 determine which decisions need to be taken 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 (and it better be important)”. 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 you begin to design you will 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 question like this, 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 are not specific enough (bad questions, divide it into one or more specific questions), or your strategy is too simple (bad strategy, continue to refine). Keep a document that captures your strategy, the questions asked, the answers and the resulting strategy updates (when changed), and make it available to everyone on the project at all times. This becomes a valuable aid in meetings 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 will 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 higher level of confidence.

Since 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 custom portions of your system and in the selection of standard devices, resulting in fewer late-stage trade-offs 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 slave devices (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, slave calls only when necessary) and you can begin to see the value in distributed design. Everything does what it does best and only what is required.

Humans operate this way all the time. For example, when I drop my shirts at the cleaners, I don''t expect to be called back, each step of the process, asking me how each shirt should be handled (what water temperature, wash with other shirts or separately, tumble dry or drip dry, press with hot iron or warm, starch or not). Or even worse, what if the cleaner waited for me to call after each step completed to tell him what actions to take next? If my selection or direction is necessary, I expect to be asked once when I drop off the shirts, and only asked to decide certain things (such as my preference for starched collars).  In other words, why burden one central (overworked) device with every action and decision. In a distributed embedded design, however, a conscious effort must be taken, a deliberate effort applied.

Simple Example: Front Panel Controller with I2C IO Expander Devices

The simplest embodiment of this concept is a system that controls the front panel of a piece of equipment. The front panel consists 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 or embedded Windows or Linux computer), and for the slaves we will select from the dozens of I2C bus-connected input/output expander devices available off-the-shelf (Philips, the inventor of I2C, offers many of these, but so do a dozen other companies, many of which are pin-for-pin and function-for-function replacements).

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. Here is a picture of this simple 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?” The answer is partly my 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.

Simple hardware and, since all the control is in the master, change is easy. The drawback of this simple approach is that it is limited in its reach. What happens when you want to, for example, add an ambient light sensor that adjusts the brightness of LEDs? 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 has not changed: it still just wants to know what buttons are pressed and command LEDs to turn on and off.

Why not create custom I2C Slave devices and off-load the Master?

This is exactly what the astute designer should be asking right now, and most experienced program managers can provide the stock answer: Because it is a “custom I2C slave”, and we won’t get it right, on-time/on-schedule (because it never happened before). But this isn’t necessarily the case and shouldn’t be accepted as common wisdom. With a little planning and the right approach, custom slave devices can deliver the goods.

If you remember our strategy, in what way did the original design fail to satisfy it? First, all intelligence was contained in the master and the slaves required near-constant attention. To be fair to the off-the-shelf solutions, there are some specific devices that address the original problem we defined 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.{{分頁}}

The question remains, how do you create the custom device without the usual pain? Use 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. To find out the details of this protocol, look into any of the Philips I2C slave devices, but here is the summary:

• 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 device has an internal address register that maintains a pointer to an internal “table” of data, commands, or status
• Each slave device defines the addresses of its registers and their function, including whether they are 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, and if any more bytes are in the transaction, they will be written to the slave device 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

As you can see, the attraction of an I2C slave is that it looks like a dual-port RAM, and it is almost as easy to use.

Now to select the programmable device, and this will be a very personal choice, but the key factors are the ability for devices to support a wide range of needs without re-learning (i.e. time-consuming learning curve issues with hardware and tools that can drive a project to a halt). The microcontroller-like devices from Cypress called PSoC, offer all the features necessary to handle most I2C slaves and provide an easy-to-use tool that makes adding I2C slave capability as easy as “drag, drop, choose address”.

First, let us define the pushbutton input slave device, creating a device with three address pins (easy upgradeability) and 7 pushbutton inputs, configured to accept a normally open switch that closes to system power (assumed to be 5 volts DC). The pushbutton 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 (at 10mA) 8 LEDs, separated into four red and four green. A single byte called “Command” is defined to act 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.

We could stop here, having provided a customized version of the off-the-shelf devices from our initial example, or we could continue and define the custom I2C master/slave interface in more detail, again using the specifics from our project (or the host of projects in our company) further allowing customization of the slave level. We would likely add an output line to the pushbutton input device if we wanted to change the system master from a polling to an interrupt device that is alerted, for instance, when the state changes for any pushbuttons. These are refinements that can further isolate the main system processor from the low-level details and provide greater freedom to continue to improve our subsystems without impacting the main system.

Extending Divide and Conquer from I2C to Any Communications Bus

The concepts discussed and shown are not unique to any particular communication bus type. What is required is to define the protocol that satisfies your strategy (which may include minimizing transmission time in a wireless, battery-operated system, or robust error detection/correction in a harsh industrial environment). The master may be called a hub and not be the initiator, and the slave may be called a node and have a scheduled response time, but the concepts of Divide and Conquer still apply – distribute the mundane, repetitious measurement and low-level control to the lowest point and save major activity for the system controller. And in every case establish strong, well-defined interfaces that leave the designer of the next level the freedom to change the implementation without affecting the higher-level components.