Developers have a range of wired and wireless mechanisms to connect microcontrollers to their peers (Table 1). On-chip peripherals often dictate the options, but many of the interfaces are accessible via off-chip peripherals. External line drivers and support chips are frequently required as well.
There’s a maximum speed/distance tradeoff with some interfaces such as I2C. There also are many proprietary interfaces like 1-Wire from Maxim Integrated Products. Likewise, many high-performance DSPs and microcontrollers have proprietary high-speed interfaces.
Some Analog Devices DSPs have high-speed serial links designed for connecting multiple DSP chips (see “Dual Core DSP Tackles Video Chores”). XMOS has proprietary serial links that allow processor chips to be combined in a mesh network (see “Multicore And Soft Peripherals Target Multimedia Applications”).
PCI Express is used for implementing redundant interfaces often found in storage applications using the PCI Express non-transparent (NT) bridging support. High-speed interfaces like Serial RapidIO and InfiniBand are built into higher-end microprocessors, but they tend to be out of reach for most microcontrollers since they push the upper end of the bandwidth spectrum. Microcontroller speeds are moving up, but only high-end versions touch the gigahertz range where microprocessors are king.
Ethernet is in the mix because of its compatibility from the low end at 10 Mbits/s. Also, some micros have 10- or 10/100-Mbit/s interfaces as options. In fact, this end of the Ethernet spectrum is the basis for many automation control networks where small micro nodes provide sensor and control support (see “Consider Fast Ethernet For Your Industrial Applications”). Gigabit Ethernet is ubiquitous for PCs, hubs, and switches with 10G Ethernet.
This article primarily looks at hardware and low-level protocols. Many applications can be built utilizing this level of support. Higher-level protocols like CANopen, DeviceNet, and EtherNet/IP target industrial control applications.
Peripheral Networks
RS-232 normally isn’t used for networks. It’s one of the most common ways of hooking up devices, though, and embedded motherboards sport lots of serial ports. RS-422/425/485 can run point-to-point, but their multidrop capability has been used in the past and continues to be used today. There’s a definite tradeoff in maximum baud rate versus distance, but these networks are still very useful.
These serial interfaces just define the electrical and signalling characteristics. This is useful because the serial ports on most microcontrollers can be configured to handle a range of low-level protocols. The next level up allows asynchronous and synchronous protocols like High Level Data Link (HDLC) to ride atop the hardware. Higher-level protocols like Modbus employ these standards.
SPI is a serial interface that is primarily used in a master/slave configuration with the microcontroller controlling external peripheral devices. Designed to make devices as simple as possible, it’s essentially a shift register. These days the slave might be a micro. SPI can be used in a multimaster mode, but it requires extra logic. It also tends to be non-standard and used in very few applications that normally need to share an SPI device between two hosts.
USB is in the same boat as serial ports and SPI. It’s ubiquitous for peripheral devices from mice to printers. It may look like a network, but it is host-driven. USB-on-The-Go (OTG) allows a device to become a host, enabling a camera to control a printer or be attached to a PC as a storage device. USB 3.0 even operates in full duplex, but the host is still in charge.
I2C Networks
Developers often use I2C for peripheral support like that provided by SPI and USB. In its basic form, it’s a master/slave architecture. But it also can operate in a multimaster mode that allows a network of devices to communicate with each other. The I2C protocol (Fig. 1) utilizes two wires: SDA (data) and SCL (clock). In its simplest form, a single master controls the clock and initiates communication with slave devices.
I2C normally uses an open-drain interface requiring at least one pull-up resistor per wire. Longer runs often place resistors at either end of the wire, allowing a dominant (0) and recessive (1) state in controller area networking (CAN) parlance. More than one device can invoke the dominant state without harming other devices. In other point-to-point interfaces, simultaneous invocations would tend to fry the drivers. The logic levels are arbitrary but often related to voltages, so 0 (logical), 0 V, and ground seem to work together nicely.
I have shown the logical connection to the two wires with separate connections for the transmit and receive buffers. In general, the transmit and receive lines are tied together within the microcontroller that exposes a single connection for the world for each wire because the transmit buffer drives the bus directly. This is different from CAN, which normally uses external buffers. Note that CAN uses two wires but in a balanced mode for a single signal versus the two signals for I2C.
The pull-up resistors hold the I2C bus in the recessive state (1). The transmitters with their open drain generate the dominant state (0). Any number of transmitters can be on at one time, but the amount of current will be the same. It is simply split between all active devices.
The basic I2C protocol is based around a variable-length packet of 8-bit bytes. The packet’s special start and stop sequence is easy to recognize. The clock is then used to mark the data being sent.
The packet starts with a header that’s 1 or 2 bytes depending upon the type of addressing being used. A single byte provides 7-bit addressing supporting 128 addresses. Of these, 16 are reserved, allowing for 112 devices.
Four of the reserved addresses are used for 10-bit addressing. The first byte contains two bits of the address, and the second byte contains the rest of the address. Most devices support and recognize both addressing modes. If not, they utilize one or the other.
A negative acknowledgement (NAK) bit that a device can use to provide a NAK follows the bits in each byte. Most devices do not. Likewise, devices can extend or stretch the clock by driving the clock line to the dominant mode. This is normally done where timing is an issue and a device needs some additional time to generate or process data. NAKs and clock stretching aren’t used often, and the host must support them.
The last bit (R) of the first byte of the packet specifies the direction of the data transfer. If the value is 1, the selected device sends the subsequent data. The host controls the clock, and the device needs to keep up unless clock stretching is used. The data has no error checking associated with it, although error checking could be done at a higher level. The host controls the amount of data.
A device can utilize more than one address and typically does. Different addresses are used for controlling different registers on a device such as an address register. This is often the case for I2C serial memories where an address counter register is loaded first. Subsequent reads or writes increment the address register with each byte being sent or received.
I2C has a number of close relations including System Management Bus (SMBus) and Power Management Bus (PMBus), an SMBus variant. The Intelligent Platform Management Interface uses SMBus (see “Fundamentals Of The Intelligent Platform Management Interface (IPMI)”). Multimaster operation comes into play in applications like IPMI and SMBus.
There are two ways to approach the problem. The first is to use a token passing scheme to avoid conflicts. The other is to use collision detection, which is the most common and standardized approach. In collision detection, the master tracks what it transmits and what is on the bus. If they differ, then there’s a collision and the master needs to stop transmitting.
There is no effect on the other master driving the bus as long as that master detecting the collision stops immediately. This is true even if multiple masters are transmitting. For example, in a 10-bit address mode, the masters may not detect the problem for half a dozen bits into the first byte assuming the clocks are close or in sync.
Slave devices don’t have to worry about multimaster operation because they will always operate in the same fashion. It isn’t possible to initiate a read and write to a device at the same time. One direction always has priority and the slave device responds accordingly.
All masters must support multimaster operation. A non-multimaster master on an I2C network will eventually stomp all over the transmission of one of its peers. Also, there is no priority or balancing mechanism, so an I2C network won’t be a good choice if lots of collisions are anticipated.
Like SPI, I2C was designed to require minimal hardware, although more than SPI. These days the amount of hardware is less of an issue as software and higher-level protocols become more important. Also, like SPI, I2C is easily implemented in software.
I2C hardware is available to handle features like address recognition and multimaster support. Address recognition sometimes can be used to wake a device from a deep sleep. Multimaster support often uses DMA support and automatic retransmission.
Controller Networking
Field-bus networks have been used in process automation for decades. Modicon initially developed Modbus in 1979. It could operate on a serial RS-232/422/425 connection including a multidrop mode. It supports a 7-bit ASCII mode and an 8-bit remote terminal unit (RTU) mode. The high-level Modbus protocol was moved on to Ethernet with Modbus TCP/IP.
A German consortium started Profibus in 1987. It supports multidrop RS-485, fiber optics, and Manchester Bus Power (MBP) connections. Profinet is a high-level protocol suitable for TCP/IP and Ethernet.
Robert Bosch GmbH developed CAN in 1983. It uses a single signal but is typically implemented using a balanced wire pair (Fig. 2). CAN initially targeted automotive applications where separate, robust drivers were a requirement. A host then provides separate transmit and receive signals to external drivers that are connected to the CAN bus.
Wired CAN is the most common network implementation, but optical versions are available as well. Most CAN drivers provide varying levels of bus isolation. Some provide optical isolation. The microcontroller and half the driver chip then can share a power supply while the bus uses another. This is very handy in electrically noisy environments such as automotive applications.
The CAN standard now defines two data frames in addition to other control and status frames with a similar format (Table 2). The two different data frames allow for an 11-bit and 29-bit address. Both are limited to 16 bytes of data. That may not seem like much, but CAN is designed for control applications where many messages with a small amount of data will be common. Operations such as reprogramming the flash memory of a device are possible, but they take a lot of packets.
CAN also turns the conventional addressing scheme on its head. I2C and conventional networks like Ethernet, Serial RapidIO, and InfiniBand employ a destination address. I2C doesn’t have a source address since it’s usually a single master platform, but the other networks typically include a source address as well.
With CAN, the address fields are used to describe the contents of the packet, not the source or destination. In fact, a packet may be sent without any device on the network doing anything with it.
Typically, a CAN packet is generated in response to an external event such as a switch closing or a sensor changing. Each event has its own address, so more than one device can send the same type of message. It also means that a packet is broadcast and any number of devices might utilize the information. A single event like a switch closure could initiate actions on a number of devices such as turning on a light or unlocking a door.
An application normally allocates addresses in blocks so they can essentially include data when simple events are being specified. The packet data is used when more information is required. For example, the address may be used to indicate an error, and the data provides the type of error.
CAN includes error checking for each packet via a 15-bit cyclic redundancy check (CRC). The CRC is on the entire packet, not just the data field, which might not even exist. There’s also support for acknowledgement and retransmission among other features. Most of these features are built into CAN hardware, though it’s possible to implement CAN in bit-banging software.
Usually, CAN hardware has a set of send and receive buffers that may be implemented with RAM and DMA support. Addresses normally are recognized with masks on the receive side along with various settings so the hardware can respond automatically. The CAN hardware then can capture packets of interest while ignoring others.
Although CAN packet addresses describe the contents, they can be used as destination addresses as well. In this case, a unique device would recognize a particular address or typically a batch of addresses. Functions can be associated with the address or specified in the packets. The higher-level protocols used on a CAN network would control how this works.
Higher-level protocols built on CAN include protocols like CANopen and DeviceNet. Initially based on CAN, these protocols also have been mapped to other networks like Ethernet. The Open DeviceNet Vendors Association (ODVA) manages DeviceNet. It’s now part of the Common Industrial Protocol (CIP), which also includes EtherNet/IP, ControlNet, and CompoNet.
CAN in Automation (CiA) manages CANopen. Like DeviceNet, CANopen provides a way for vendor hardware to coexist. Devices must support the higher-level protocol. These frameworks provide a way to query and control devices including high-level interfaces to standard device types.
OpenCAN should not be confused with CANopen, though. OpenCAN is an open-source project that provides an application programming interface (API) for controlling a CAN network.
Automotive Networking
CAN started out in the automotive industry and is still heavily used there. But, as noted, CAN also is utilized a lot in other areas such as process control.
CAN’s speed and data capacity weren’t enough for some of the latest demanding automotive applications including drive-by-X, so Flexray was created. This network is strictly for automotive use and is supported on a limited number of microcontrollers. It runs at 10 Mbits/s and supports time-trigered and event-triggered operation. Like CAN, it’s fault tolerant. It’s also deterministic.
Likewise, the local interconnect network (LIN) is an automotive network that also can be used in non-automotive applications. It uses a master/slave architecture with up to 16 slave devices. It’s normally tied to a CAN backbone with LIN providing lower-cost control support such as panel switch and button input. It’s slow and uses a single wire. It also uses a checksum for error detection.
Media Oriented Systems Transport (MOST) is a multimedia network for automotive applications used in some high-end vehicles. It runs up to 150 Mbits/s. However, it’s being challenged by Ethernet (see “Automotive Ethernet Arrives”) from the OPEN Alliance (One-Pair Ether-Net). Ethernet uses a single twisted pair that can deliver power too. It runs up to 100 Mbits/s and uses standard Ethernet protocols. Also, it supports the 802.1BA audio/video bridging (AVB) standard.
Ethernet Networks
Arcnet and Token Ring are long gone. InfiniBand and Serial RapidIO take the high ground targeting applications like supercomputing and communications. Applications that use these networks have dedicated controllers or a very high-performance microprocessor or system-on-a-chip (SoC). Ethernet can play with these big boys, but it’s found where they aren’t—on microcontrollers.
10-Mbit/s Ethernet and 100-Mbit/s Ethernet are alive and well in microcontrollers even though most microprocessor and SoC systems have moved on to 1-Gbit/s Ethernet. External Ethernet interface chips for the low end often have SPI, I2C, and low-pin-count (LPC) interfaces. And, Ethernet supports the IEEE-1588 time synchronization standard, which can be used in embedded applications to synchronize the clocks on each node (see “Keeping Time Ethernet-Style”).
More advanced applications may need real-time Ethernet support. Standards such as EtherCAT provide an alternative to standard Ethernet (see “Using The EtherCAT Industrial Communication Protocol In Designs”). EtherCAT can be part of a regular Ethernet network and data can flow between the two networks, but the EtherCAT side has more control over the protocol, allowing data to be analyzed on the fly.
Industrial Ethernet networks provide better timing and error support than the standard Ethernet implementations that leave most of these details to software (see “Industrial-Strength Networking”). Hardware allows Ethernet to be used in applications such as motion control that would be difficult with conventional Ethernet support.
As noted, most of the field bus protocols support Ethernet. Some extend to the industrial Ethernet hardware platforms.
Wireless Networks
Developers can find as much variety in microcontroller-supported wireless networks as in wired networks. Many proprietary solutions operate in the industrial, scientific, and medical (ISM) bands. Bluetooth, ZWave, and 802.15.4, which includes ZigBee and Wi-Fi, also are available.
The protocol stack is often one of the determining factors in whether low-end microcontrollers can handle wireless communication. The range of support is why there are proprietary alternatives based on 802.15.4 like Texas Instruments’ SimpliciTI, Cypress Semiconductor’s CyFi, and Microchip’s MiWi (see “Should You Choose Standard Or Custom P2P Wireless?”). These protocol stacks tend to be smaller and the overhead lower for lower-power operation.
Wireless operation can be a single-chip solution at the low end where Bluetooth and 802.15.4 platforms operate, but Wi-Fi tends to be a separate chip. Sometimes some or all of the protocol can be offloaded to the support chip or module. Some modules utilize a serial interface and an AT-style command set to support anything from sending packets to e-mail.
The protocol stacks or modules tend to hide the details of the wireless interface from most developers, but they still will be responsible for the network topology. Bluetooth provides a master/slave hierarchy that is relatively simple.
Other platforms, especially proprietary ones, provide point-to-point communication or star network support. More advanced wireless protocols like ZigBee support mesh networking so data can be passed from one node to another. This type of router operation is how the Internet works, but in a wireless only form.
Wi-Fi, especially 802.11b/g, usually can be supported by any microcontroller that could also support Ethernet, which is quite a few. A system generally would not support both unless it was for a gateway application.
The Wi-Fi modules can be extremely compact. I recently used a Gumstix AreoStorm module to control an iRobot Create using the TurtleCore module, also from Gumstix (see “TurtleCore Tacks Cortex-A8 On To iRobot Create”). The AreoStorm is based on the Texas Instruments Sitara AM3703, which in turn is based on Arm’s Cortex-A8 core. It includes a Wi-Fi (802.11b/g) and Bluetooth wireless module based on Marvell’s W2CBW003C chip.
Embedded developers may also want to take a closer look at WiFi Direct, which provides Bluetooth-style device connectivity between Wi-Fi devices. WiFi Direct support depends on software and hardware, so not all platforms can support it.
Cellular is another wireless platform. Its support tends to be at the module level since it requires integration with service providers.
Powering Network Devices
Power delivery is frequently overlooked in microcontroller networks. It isn’t an issue for on-board networks or rack-based boards, but it does arise for remote devices. Solutions often are proprietary. For Ethernet-based networks, a standard interface is available. Power over Ethernet (PoE) uses conventional CAT5 and CAT6 cables to provide more than 25 W to a device.
Super Micro Computer’s SSEG2252P Gigabit Ethernet switch boasts 52 ports. Its 400-W PoE budget can be selectively delivered to any set of ports. The maximum power per port is 34.2 W, although the average is 7.5 W if 48 ports are supported. Each port has a priority, so if the system is over budget, low-priority links won’t get power.
Wireless solutions often work well with projected power. There are many options in this area. PowerCast provides a range of wireless power broadcasting solutions that can support an 8-bit Microchip PIC (see “PIC Module Runs Off RF Power”) or charging a battery for a Texas Instruments MSP 430 (see “Battery Charged Remotely Using RF Power”).
In general, these types of wireless power solutions have a transmitter and a receiver. The receiver provides power and sometimes battery backup to a device. Another alternative, power scavenging, tends to work well for applications that require very little power since the power source is often limited. It may be solar, vibrational, or a host of other mechanical sources.
The application often will dictate the choice of network and power source, though designers sometimes have the flexibility to choose. Knowing the alternatives is a good starting point.