Slave nodes
I2C network
MCU connected
Network specifications
The serial peripheral interface (SPI) and universal asynchronous receiver/transmitter (UART) have become the popular communications protocols for microcontroller-based industrial systems. For embedded systems that require greater robustness and connectivity, controller-area network (CAN) and Ethernet are the first choices for many developers.
While all of these protocols support transfer speeds greater than 1 Mbit/s, they’re still used in lower-bandwidth applications because they’re well understood and supported.
Local interconnect network (LIN) and inter-integrated circuit (SMBus/I2C) are two viable alternatives for non-bandwidth-intensive applications. These two protocols offer a number of benefits for embedded systems, and they often become an ideal choice relative to other protocol options for industrial applications.
LIN Protocol
Historically, LIN has been used in automotive systems. But its advantages such as low-pin count, data integrity, easy implementation, and standardized application interface fit many embedded applications.
The LIN Consortium created the LIN bus standard to provide a common communications platform for vehicles. Some of the primary design constraints for the protocol included low cost, high reliability for data transfer, and the high reliability for the hardware itself due to a demanding operating environment.
A LIN network exhibits the simplicity and low-cost development benefits of the UART and SPI protocols, but offers data reliability and some scalability provided by CAN and Ethernet. To understand how this network meets these design goals and offers other benefits, it’s helpful to examine the standard network architecture.
LIN networks contain a single master node and up to 16 slave nodes (Fig. 1). At the system level, the master nodes are typically powerful MCUs, and the slave nodes are simpler MCUs or ASICs. The LIN network is a serial broadcast network that supports baud rates up to 20 kbits/s. Nodes connect to the same single-wire bus via transceivers.
At the physical layer, the master initiates all data transfers, which are then transferred in frames measuring up to 8 bytes in length. Each frame includes a synchronization break field, a synchronization byte, an identifier byte, data bytes, and a checksum byte.
Different types of frames will transfer data and send diagnostic messages. Unlike most communication protocol standards, the LIN specification extends to the application level and specifies an application programming interface (API) for software drivers.
Assuming that the system doesn’t require greater than 20 kbits/s of data transfer, these design specifications garner benefits for the embedded system and the system developer. From a cost-per-node perspective, LIN networks are more cost-effective to implement than comparable CAN and Ethernet networks.
Continue to next page
Also, LIN transceivers are small, eight-pin devices that are readily available for less than $0.75 in moderate to large quantities. Their low pin count helps reduce board size as well.
Furthermore, LIN transceivers are automotive-quality certified and thus tested to high electrostatic discharge (ESD) tolerance, which can mean fewer replacements coming back from the field. Ethernet transceivers target commercial applications and usually cost less than $2.
CAN networks offer similar reliability and pricing to that of LIN, but may add cost on the application development side. LIN transceivers also help limit the slew rate to assist with electromagnetic compatibility (EMC) behavior.
LIN slave nodes typically use smaller and less expensive MCUs for a number of reasons. For one, they don’t need an external crystal for system clock accuracy—the LIN specification enables slave nodes to determine the baud rate of the data transfer using the synchronization byte presented in each frame header.
Also, LIN slave nodes can be smaller in terms of flash memory size, since they needn’t implement a full LIN stack. From a network perspective, they simply must be able to respond to data requests from a LIN master.
In automotive applications, LIN slave nodes are used for specific tasks, such as motor control for sunroofs or sensor measurement for climate control. Those same tasks are directly transferable to industrial applications that require motor control and/or data acquisition.
Mastering The LIN Master Node
The amount of system development for a LIN master node depends greatly on the system requirements. The LIN specification details a procedure regarding the master node keeping a list of devices on the bus, as well as providing a methodical way for the master node to poll each slave device for its status.
For systems that require this high level of organization, LIN stacks are available for popular LIN MCUs, such as Silicon Labs’ C8051F5xx family. These stacks can be directly loaded onto the MCU.
However, for simpler systems, the LIN bus can be treated like a basic communications pipe, similar to UART interfaces or SPIs. The system developer is free to create any type of applications interface and transfer data using simple read and write functions.
Ethernet and CAN applications require a certain amount of code space for storing and interfacing with the stack. Executing the stack requires additional processing power. These requirements raise MCU cost and the time required for firmware development.
Many industrial systems include hot-swappable modular nodes. Ideally, from a system design perspective, when a node is added to a network, it should be automatically recognized and addressed. On the same note, if a network node is faulty, it should be automatically isolated and ignored.
For applications that can afford it, CAN and Ethernet offer these features inherently. For simpler applications that use UART or SPI, these features need to be added at the firmware level and require processing. LIN offers these features found in CAN or Ethernet for the same cost as UART or SPI.
Continue to next page
Checksums offer a simple way of providing data integrity for data transfers. The CAN and Ethernet protocols provide data integrity in hardware. The basic protocols, such as SPI and UART, require additional firmware.
LIN provides a good compromise between cost and firmware requirements by delivering a full checksum that covers the data and identifier fields of a frame. Typically, LIN hardware modules can generate the checksum in hardware and provide error-handling capability for the data receiver.
Non-automotive applications that can benefit from the LIN feature set include high-voltage appliances like washer/dryers and garage-door openers. Modern-day washer/dryers contain an array of sensors, motor controllers, and nodes that need to process the digital controls and displays. These systems are also subject to various EMC regulations.
Typical LIN node devices can perform these tasks. They also can provide data integrity when transferring data over the LIN network and keep emissions to a minimum.
I2C Protocol
The I2C protocol developed by Philips allows communication between multiple ICs within a system. It requires two signal lines: the serial data line (SDA) and the serial clock line (SCL). These signals are both bidirectional, open-drain lines.
Typically employed in computer motherboards or for communication between integrated circuits within a system, I2C also offers useful features: addressing, easy connectivity for devices with different input/output voltage levels, and bus error detection and recovery.
I2C is a multi-master bus, enabling any device on the bus to operate as a master, provided that the bus is free. A master node can generate a read or write to a slave device by writing a slave address on the bus and waiting to see if any device on the bus acknowledged the slave address.
If a slave address transmitted by a master is acknowledged, the slave will start receiving the data on the bus. All of the other devices will ignore the data on the bus. Every I2C transaction has a master/slave relation, in which the device acting as a master is always responsible for initiating transfer and issuing clock signal on SCL.
Each device can be accessed through its unique slave address, which is preconfigured on each of the I2C bus’ devices. The protocol includes clock stretching as a method of flow control, enabling a slave device to hold the bus until the slave device is done processing data. It also includes a method of arbitration that provides a deterministic way to resolve the problem of two masters transmitting at the same.
Although recent revisions to the I2C specification allow for transmission frequencies above 400 kHz, most of the devices currently available support speeds up to 400 kHz. Numerous manufacturers have adopted the protocol into their products thanks to its low pin count, need for only two passive external components, and simplicity of implementing I2C communications in a system.
Continue to next page
A sample implementation of a cell-phone handset illustrates an example of an I2C network (Fig. 2). The main MCU uses the I2C bus to communicate with an EEPROM that stores calibration data, a proximity sensor to configure and calibrate proximity detection, a real-time clock (RTC) that can accurately keep time and send the time back to the MCU, and a cell-phone processor.
In most cases, the MCU is the master device in the network. But when the cell-phone processor needs to access the MCU, it acts as the master device, and the MCU acts as the slave device. Here, a completely separate bus interfaces the touchscreen to the MCU.
The ability to manage an array of external devices with two lines and one MCU makes the I2C protocol an appealing choice for many applications by simplifying and reducing the size of a design. There’s no lack of options for trying to solve the challenge of communication within a system. However, most choices don’t offer the same set of benefits available from the I2C protocol. The I2C peripheral takes up little die space on an MCU. As a result, chip manufacturers can add a peripheral that supports I2C to their MCUs at a very low cost.
From a system hardware design perspective, the I2C bus is very inexpensive to implement, requiring just two passive, external components and two pins. UART, LIN, CAN, and Ethernet solutions all need an external transceiver device, which increases the size of a board and adds to the overall bill-of-materials cost.
The use of only two pins also makes I2C attractive to other communications alternatives, such as SPI. In many space-constrained applications, limiting the MCU’s pins helps reduce size, but also limits the number of available general-purpose I/O (GPIO) pins.
The number of pins required to implement I2C is independent of the number of attached devices. Rather, it’s limited by the number of unique slave addresses and the overall capacitance of the SDA and SCL lines.
Alternatively, the SPI protocol would require three pins for data transmission, as well as one additional “slave select” pin per device attached to the bus. Figure 3 shows an MCU connected to various slave devices in a system using the I2C protocol and the SPI protocol.
From a development perspective, adding or removing devices from an I2C bus simply involves attaching the SDA and SCL pins of a new device to the lines currently shared among other devices. This can allow hot-swapping of modules, reducing development time and cost. Addressing is built into the I2C protocol and doesn’t add to the code size.
In SPI and UART systems, node addressing requires extra firmware overhead. The code size of the I2C implementation is approximately 550 bytes on Silicon Labs’ MCUs, which is typically a small percentage of the available flash memory.
Another benefit of the I2C protocol is that devices with different I/O voltages are able to communicate with one another. As long as the devices’ I/O pins on the bus can tolerate the voltage that the SDA and SCL lines are pulled-up to, devices operating at different I/O voltages can communicate.
In the I 2C block diagram (Fig. 1, again), the MCU operates at an I/O voltage of 3.3 V, and the RTC operates at an I/O voltage of 1.8 V. However, they still can communicate with each other, provided that the RTC’s I2C pins are 3.3-V tolerant.
Overall Benefits
The LIN protocol provides an additional option to developers for applications that aren’t bandwidth-intensive. The low pin count, ease of implementation, addressing scheme, and data integrity make LIN a viable option for many embedded applications. The cost of implementing the protocol is low, and the protocol enables robust communications between ICs.
Similarly, the I2C protocol offers an outstanding interface solution for systems that need communication between ICs within a system. Its low-cost implementation also makes it attractive.
Through the unique slave addressing system, only two lines are needed for communication, and further devices can easily be added to the bus. Furthermore, many IC manufacturers have adopted the I2C protocol and added an I2C interface to their devices.
Comparing the key communication protocols can help designers get a better idea of what’s best for their system (see the table).