Microcontrollers Tackle Networking Chores
Total Page：16
File Type：pdf, Size：1020Kb
Microcontrollers Tackle Networking Chores 0 William Wong August 02, 2012 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. 1. An I2C network uses two control lines and is typically implemented using open drain drivers. There is a range of I2C protocols based around 7-bit and 10-bit device addressing. 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.