MCUs offer a very wide range of serial-interface choices. The selection of the serial interface may be as simple as the one required by the peripheral component, but when you have a choice of what interface to use a wise decision can make a big difference in your system’s performance. General-purpose serial interfaces like SPI, I²C, or a UART may be the most common choices, but how about more specialized interfaces like CAN, or SMBus/PMBus? When are these choices the best? This article will examine these serial interface standards in more detail, and explore some common implementations to get a better idea of the types of applications for which they are best suited.
Universal asynchronous receiver transmitter
Perhaps the most familiar serial interface is the venerable Universal Asynchronous Receiver Transmitter (UART). This simple asynchronous protocol employs a single wire to transmit data and another to receive, using the simple data frame shown at the top of Figure 1. The line starts at the idle state, a high-voltage level and a low-going edge defines the start of the data frame. Multiple-data bits follow, with the low or high level indicating the data value. An optional 8th data bit and a parity bit may be included at the end of the data frame. (The fact that the 8th data bit is optional gives you an indication of how old the standard is. Who would think of creating a modern standard with only 7 data bits?) A free-running clock, usually several times the data transmission frequency, is used to capture the data bits after the start bit. The receiver can usually “figure out” the transmission data rate by checking the data rate and windowing in on the time between the start bit and the stop bit. The data rate for a UART is typically lower than that for other serial protocols, but its simplicity and ubiquitous nature (virtually every MCU has multiple UART peripherals) make it a good fit for low- performance applications like sensors, simple controllers and for subsystem communications — either over wires or via board-to-board connectors.
Figure 1: UART Data Format and Energy Micro Low-Energy UART Operation. (Courtesy of Energy Micro)
You might think that there is little innovation possible with this type of interface, but with the continued drive for low-power operation even the familiar UART is getting attention. For example, Silicon Labs’ Energy Micro Tiny Gecko MCU devices like the EMF32TG210
include a special low-energy implementation of the familiar UART peripheral. The low-energy UART can operate independently in the low-power EM2 mode (with much of the core functionality turned off). The low-energy UART also can wait for an incoming UART frame in a very-low-power mode. When an incoming frame is detected the CPU can be woken up. Alternatively, multiple frames can be moved to on-chip SRAM using the DMA controller with CPU intervention, as illustrated in the bottom of Figure 1. For even more power-efficient operation the low-energy UART can even block data reception until a configurable-start frame is detected. Additionally, a configurable-signal frame can be used to generate an interrupt, perhaps to indicate the end of a block transfer, to wake the CPU. The data- transfer rate of the low-energy UART is limited to 9600 baud, but the 150 nA power dissipation during wait and the few uA required during active communication make this a very power-efficient approach.
Universal Synchronous Asynchronous Receiver Transmitter (USART)
Most modern MCU implementations of the general-purpose UART peripheral include not only the asynchronous operation, but add synchronous operation as well. This is common because much of the low-level hardware is similar between synchronous and asynchronous operation. Synchronous operation typically supports additional standards such as RS-485, Microwire, 3-wire, SPI, SmartCards and/or IrDA. The added circuitry required to support these additional synchronous standards does require extra power, so there are still some implementation, such as the Energy Micro low-energy UART, that leave out the additional USART overhead at least for a single UART channel.
Serial Peripheral Interface (SPI) and Inter-integrated Circuit Interface (I²C)
SPI and I²C serial ports are used for very similar purposes. They are simple serial interfaces using a minimum of signals for connecting to medium-speed peripheral devices— typically sensors, serial memory and as a configuration port for more complex devices (for example, some FPGAs, can be configured via an SPI interface).
The STMicroelectronics STM32F3
73xx family supports I²C and SPI, and here we will present it as an example showing where these ports are often used. The STM32F3
73’s I²C port can operate at 100 kHz (at standard speed), 400 kHz (at fast speed) and at 1 MHz (at fast+ speed) while the SPI port can operate at up to 18 Mbits/s. MCUs typically have multiple I²C and SPI ports and the STM32F3
73 is no exception with three SPI ports and two I²C ports. It is also not unusual for the I²C and SPI ports to support other, similar protocols. On the STM32F3
73 the I²C port can also support SMBus/PMBus for power supply configuration and control and the SPI ports can also support the inter-integrated sound interface (I²S).
SPI and I²C ports are work-horse serial ports for a multitude of applications. The simple connections (using only a few pins) and a simple protocol, along with some useful hardware features for waking the CPU during an address match or automatic transfer support with DMA make these ports the first choice for low-speed sensing, power supply control, configuration and simple communications. Only if you need higher performance will you need to consider another type of interface.
Many serial-interface peripherals have common architecture elements so a closer look at the STM32F3
73 implementation of the SPI peripheral is helpful in understanding serial-interface peripherals in general. As seen in Figure 2, the STM32F3
73 SPI port has a small number of IOs (the MOSI and MISO serial-data signals, the SCK serial clock and the NSS slave-select pin). Many serial peripherals use separate data input, data output and clock as a balance between low-pin count and high performance. A separate clock requires an additional pin over non-clock implementations, but allows higher performance since the data need not be sampled at a multiple of the data rate as in UART protocols. The slave-select input is also a common element with other serial communications implementations and it allows multiple devices to use the same signals, minimizing system-level interconnect requirements.
Figure 2: Implementation of the SPI Peripheral on STM32F373. (Courtesy of ST Microelectronics)
73 has separate transmit and receive FIFOs that help offload low-level communications management from the CPU. A shift register, ubiquitous in serial-communications implementations, is used to hold data being transmitted or received by the peripheral. An integrated-baud-rate generator, to determine clocking rates, and a hardware CRC block to offload any low-level error checking from the CPU are welcome hardware elements and are also common to many serial-peripheral implementations. Finally, a bus interface from the peripheral to the rest of the system is required, and many implementations include a bus matrix and DMA control to prioritize data transfers and further improve efficiency. Other serial-port implementations will have similar architectural elements and you should look for those implementations that provide useful hardware blocks matching your application requirements.
STMicroelectronics provides a discovery kit for STM32F3
microcontrollers that is helpful to engineers in utilizing and applying these MCUs.
The SMBus is a simplified version of I²C bus (with just clock and data) and was initially defined to communicate ON/OFF instructions to a power source — typically an on-board module or regulator. Most MCU I²C peripherals can be used to control an SMBus, but there are exceptions, so check carefully if an SMBus is needed in your design. The PMBus is a slightly more complicated implementation, but still easily supported by most MCU I²C ports, that more clearly defines some of the attributes of a compliant device (instead of primarily defining a protocol for communication as in SMBus). The choice of PMBus versus SMBus will be primarily dictated by the power control system, since MCU support is usually easily available.
Controller Area Network (CAN)
The CAN protocol was primarily designed to be used as a vehicle-serial-data bus, meeting specific requirements for real-time processing and reliable operation in the noisy environment of a vehicle. Cost-effectiveness at the required bandwidth is also a key goal. CAN has also been adopted more widely for motor control and industrial automation where similar real-time and reliability requirements exist.
Even though CAN uses only a single-data transmit signal and a single-data receive signal, it is a much more complex protocol that the ones we have discussed previously. Fortunately much of the low-level details are supported automatically by the peripheral and the user can focus primarily on higher-level aspects of the design. As an example implementation, Freescale Kinetis K30 MCU devices like the MK30DX256
feature a very flexible implementation of the CAN protocol, as illustrated in Figure 3, and will help illustrate some of the key considerations when designing with more complex protocols.
Figure 3: Freescale Kinetis MK30DX256 MCU CAN Controller. (Courtesy of Freescale)
The FlexCAN module on the Freescale Kinetis MK30DX256
is a full implementation of the CAN protocol specification, Version 2.0 B. It is best considered as a protocol controller instead of just a simple interface because it hides much of the low-level elements of the design from the user. (The details of the CAN physical layer are actually very interesting, and in many respects reminiscent of Ethernet, but are beyond the scope of this article. Refer to the CAN specification¹ if you are interested in learning more.) Communication across the two-wire interface is handled by the controller and the resulting messages are stored in a local-message-buffer RAM.
In the Freescale Kinetis MK30DX256
implementation the CAN Protocol Engine (PE) sub-module manages the serial communication on the CAN bus, requesting RAM access for receiving and transmitting message frames, validating received messages and performing error handling. The Controller Host Interface (CHI) sub-module handles Message Buffer selection for reception and transmission, taking care of arbitration and ID-matching algorithms. The Bus Interface Unit (BIU) sub-module controls the access to and from the internal-interface bus, in order to establish connection to the CPU and to other blocks. The flexibility associated with the FlexCAN controller is done via a host of configuration registers (31 32-bit registers) that control various operating modes, mask registers, error counters, interrupt registers and FIFO controls.
Although CAN is primarily targeted at automotive applications it can be used in many industrial applications as well. Motor control, for example, is an application where CAN’s resistance to noise (in the form of electromagnetic interference, or EMI) can be a big benefit. Factory floors that have significant requirements for robust operation, operational redundancy and low-speed requirements may find CAN a better option than less robust serial interfaces or more complex solutions like industrial Ethernet. Now that more low-cost MCU’s are supporting CAN, along with better availability of CAN drivers and protocol stacks, CAN might be worth a more in-depth look as a possibility in your next industrial control project.
Software support is key
In these types of more-complex peripherals the large number of configuration registers can be daunting, and getting every configuration bit set correctly can be the source of much frustration. Fortunately MCU manufacturers have realized this and typically provide a facility for easily setting the various configuration bits required for common-operation scenarios. Freescale, for example, provides the Processor Expert tool² that generates C code to create, configure, optimize, migrate and deliver software components, such as peripheral drivers, as a starting point for your software-development process. Processor Expert uses a simple graphical user interface to select components from a library, configure them using a guided process that eliminates errors and conflicts (common when doing this task “by hand”) and then installs them in your software project for use by the IDE during software development. This type of tool is almost a hard requirement when designing with complex peripherals to avoid costly errors and configuration conflicts. A short video3 provides a quick overview of this process.
In many applications the well-known low-bandwidth UART may be the most familiar choice, but now that MCUs are providing a wide range of other low- and medium-bandwidth serial-interface solutions, like SPI, I²C, PMBus and CAN it is useful to look at other options as well. With software tools that help “hide” much of the detailed low-level hardware functions from the user, not only will you end up more interface performance, but your development time will be reduced as well.
For more information on the parts discussed in this article, use the links provided to access product information pages on the Hotenda website.
- ISO Standard for CAN Physical Layer
- Freescale Processor Expert Tool
- Processor Expert Video Overview