Tag Archives: I2C

UART, SPI,I2C and More

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Pretty much every FPGA design has to interface to the real world through sensors or external interfaces. Some systems require large volumes of data to be moved around very quickly, in which case high-speed communications interfaces like PCI-X, Ethernet, USB, Fire/SpaceWire, and CAN, or those featuring multi-gigabit transceivers may be employed. However, these interfaces have a considerable overhead in terms of system design and complexity, and they would be overkill for many applications.

Systems with simple control and monitor interfaces — systems that do not have large volumes of data to transfer — can employ one or more of the simpler communications protocols. The four simplest, and therefore most commonly used, protocols are as follows.

    • UART (Universal Asynchronous Receiver Transmitter): This comprises a number of standards defined by the Electronic Industry Association (EIA), the most popular being the RS-232, RS-422, and RS-485 interfaces. These standards are often used for inter-module communication (that is, the transfer of data and supervisory control between different modules forming the system) as opposed to between the FPGA and peripherals on the same board, although I am sure there are plenty of applications that do this also. These standards defined are a mixture of point-to-point and multi-drop buses.

 

    • SPI (Serial Peripheral Interface): This is a full-duplex, serial, four-wire interface that was originally developed by Motorola, but which has developed into a de facto standard. This standard is commonly used for intra-module communication (that is, transferring data between peripherals and the FPGA within the same system module). Often used for memory devices, analog-to-digital converters (ADCs), CODECs, and MultiMediaCard (MMC) and Secure Digital (SD) memory cards, the system architecture of this interface consists of a single master device and multiple slave devices.

 

    • I2C (Inter-Integrated Circuit): This is a multi-master, two-wire serial bus that was developed by Phillips in the early 1980s with a similar purpose as SPI. Due to the two-wire nature of this interface, communications are only possible in half-duplex mode.

 

  • Parallel: Perhaps the simplest method of transferring data between an FPGA and an on-board peripheral, this supports half-duplex communications between the master and the slave. Depending upon the width of data to be transferred, coupled with the addressable range, a parallel interface may be small and simple or large and complex.

Over the next few weeks, I will be exploring each of these protocols in depth, explaining their histories, pros and cons, and typical uses. Also, I will be discussing how to implement these protocols inside an FPGA (there may even be some code floating about as well).

But before we examine these protocols in depth, it’s well worth our while to spend a little time recapping some of the terminology we use when describing protocols and their behavior, as follows.

  • Point-to-point: The simplest of communication protocols that involves just two devices exchanging data (a common example is RS-232).
  • Multi-drop: A more complicated structure that consists of a single master and a number of slaves, thereby facilitating more complicated data transfers and control architectures. Some protocols, such as I2C, can have multiple masters.
  • Simplex: This refers to data communication that is unidirectional. A typical implementation of a simplex data link could be a sensor broadcasting data to an FPGA or a microcontroller.
  • Duplex: This term is used when discussing point-to-point links. The ability of a protocol to support communication in one direction at a time is referred to as “half duplex.” If the protocol can support communication in both directions simultaneously it is referred to as “full duplex.”

As we discuss the different protocols in future columns, we will also be referring to the Open Systems Interconnection (OSI) seven-layer model. This is an abstract model used to describe how protocols function.

  • Layer One: Physical Layer. Describes the physical interconnection.
  • Layer Two: Data Link Layer. Describes the means for actually transferring data over the physical layer (Physical Addressing).
  • Layer Three: Network Layer. Describes the means to transfer data between different networks (Logical Addressing).
  • Layer Four: Transport Layer. Provides transfer of data between end users.
  • Layer Five: Session Layer. Controls the connections between end users.
  • Layer Six: Presentation Layer. Transforms data presentation between higher-level and low-level layers.
  • Layer Seven: Application Layer. Interfaces to the final application where the data transferred to is used or data is gathered for transfer.

It is worth noting at this point that not all layers of the OSI model are required to be present within a particular protocol. We will see examples where only a subset of the layers is employed.

As an aside, while I was writing this, I thought about some of the more obscure EIA protocols out there, such as RS-423, RS-449, and EIA-530.

Facebooktwittergoogle_plusredditpinterestlinkedinmail