An Overview of the I²C Bus (Japanese blog)
0. Table of Contents
table of contents
What is I²C?
1.1 History and specifications
1.2 Controller/Target
Physical/Electrical Characteristics
2.1 Number of signal lines: SDA, SCL
2.2 Open-drain output (wired-AND)
2.3 Clock Frequency
2.4 Connection Topology
protocol
3.1 Required and optional features
3.2 Data Transfer Unit
3.3 Bus state: Start and end of transfer
3.4 Transaction Structure
3.5 Write and Read Transactions
Reference materials
1. What is I²C?
1.1 History and specifications
The I²C (I-squared-C) bus is a serial bus specification developed and released in 1982 by Philips (now NXP Semiconductors) of the Netherlands. I²C is an abbreviation of " Inter Integrated Circuit " which is written as "IIC" with the overlapping "I" squared.
At the time this bus was developed, television and radio circuits were still being adjusted and set using variable resistors, variable capacitors and screws on the cores of coils. I²C began to be used as a bus to replace these components and to allow controllers to be built into devices and factory computers in order to control and automate each function.
For this purpose, the original clock frequency was set to 100 kHz and large amounts of data transfer was not anticipated.
When I joined Philips in the late '80s, the lab was equipped with CCTV (Computer Controlled TV) and other equipment to demonstrate this concept.
The current I²C specification is managed by NXP Semiconductors , a company formerly formed by Philips' semiconductor division. This specification is published as the " I²C-bus specification and user manual " ( document number UM10204 ) , with the latest version being Rev.7. The Japanese version , Rev.5, has been published as the " I²C bus specification and user manual ." The differences between Rev.5 and Rev.7 are changes to Figures 41 and 42, an addition to Table 5, the change of the terms master/slave to controller/target, as in I3C, and the addition of "I3C Overview" in Chapter 9 (see Table 1: Revision History in Rev.1 for details). As these differences do not affect the main parts of the I²C specification, the Japanese version can be used as a reference.
1.2 Controller/Target
I²C communication always takes place in a master-slave relationship. The terms used to refer to these roles are controller and target , respectively [Figure 1].
Figure 1: Controller and Target
The specification allows multiple controllers to exist on one I²C bus.
Older specifications used the terms "master/slave", but this has now been changed to "controller/target".
2. Physical/Electrical Characteristics
2.1 Number of signal lines: SDA, SCL
I²C is a two-wire serial bus, one for the clock and one for the data . Since data is exchanged synchronously with the clock, it is classified as a "synchronous serial interface."
Data communication can be done in both sending and receiving directions, but because it is done over a single data line, these cannot be done simultaneously and must be switched between. For this reason, it is a communication method called half-duplex , rather than full-duplex, which allows simultaneous sending and receiving.
The clock and data signal lines are called SCL (serial clock line) and SDA (serial data line) , respectively.
Data is transmitted or received one bit at a time in synchronization with the clock cycle.
2.2 Open-drain output (wired-AND)
One of the distinctive features of I²C is that signals are generated using a method called "open drain."
In many communications, a method called push-pull is used to output digital signals. Push-pull is a method in which a specified voltage is output (pushed) on the signal line when a HIGH signal is output, and a LOW signal is pulled to GND (pulled) [Figure 2-a].
Open drain is similar to "pull" in that it outputs LOW, but when it outputs HIGH it goes into a high impedance state. In this state, a pull-up resistor connected to the signal line ensures that the specified voltage is obtained [Figure 2-b].
Figure 2-a: Push-pull output
Figure 2-b: Open-drain output
So why is this output method used?
This is because I²C allows multiple devices to output to the same signal line simultaneously. When multiple devices are in an output state, if even one device is outputting LOW, the signal will go LOW.
This method of connecting a signal that is HIGH when all devices output HIGH and LOW otherwise is called " wired-AND " [Figure 3].
Figure 3: Wired and connected
I²C has optional features called " clock stretching " and " multi-controller ." These allow multiple devices connected to the same bus to output simultaneously, and manage their status using open-drain connections.
The I²C HIGH voltage is not specifically defined in the specifications. The power supply voltage (VDD) to which the pull-up resistor is connected varies depending on the device. When communicating, a voltage that can be used commonly between connected devices must be used. In many cases, voltages such as 5V or 3.3V are used for VDD, but in SoC chips and other devices where voltages are becoming increasingly low, voltages of 1V or less are sometimes used. The signal voltage for I²C input is set to LOW at 0.3VDD or less , and HIGH at 0.7VDD or more , so when connecting I²C buses with different voltages, a " signal voltage converter ( VLT : voltage level translator)" must be used. To convert this signal voltage, you need to select a device that can be used with I²C, taking into account that it is a bidirectional open-drain signal.
With I²C, you must also take into account the analog behavior of signals. This is the time it takes for the signal output to change due to the open drain. The fall time is fast when going from HIGH to LOW, but the rise time when going from LOW to HIGH can be slow depending on the state of the bus. Specifically, the rise time becomes slower as the number of connected devices increases or the length of the signal line becomes longer. This occurs because the capacitance of the signal line increases [Figure 4].
The allowable capacitance is capped by each mode, which dictates the maximum I²C clock speed.
Figure 4: Capacitance and signal rise time
2.3 Clock Frequency
I²C defines " modes " based on the maximum clock frequency that can be used [Table 1]. The most basic mode is called standard mode ( Sm ) and operates below 100kHz . Next there is the fast mode ( Fm ) with an upper limit of 400kHz. These Sm and Fm modes are supported by most controllers and targets .
There is also Fast Mode Plus ( Fm+ ), which can operate at clock speeds of less than 1MHz and is used for applications with high data rates.
Furthermore, there is a high-speed mode ( HS-mode or Hs ) with a maximum speed of 3.4MHz . This high-speed mode has a specified protocol for switching to communication at this speed, and a bridge is required to mix communication with other modes. There are not many devices equipped with controllers that support this mode.
An ultrafast mode is also specified for special applications. This has a clock upper limit of 5MHz and limits communication direction to one direction from controller to target, making it incompatible with other modes.
When "I²C" is used without mentioning the mode, it often refers to the most common standard mode or fast mode, and this blog will be based on these modes.
mode
Abbreviation
Maximum Clock Frequency
remarks
Standard Mode
Sm
100kHz
The most popular mode
Generally speaking, I²C refers to up to Fm compatible with 400kHz.
Fast Mode
Fm
400kHz
First Mode Plus
Fm+
1MHz
Specifications with expanded speed, current draw, and bus capacity
Controllers with this capability are installed in many microcontrollers.
High Speed Mode
Hs
3.4MHz
There aren't many adoption cases
Compatible with Sm and Fm. Switch to Hs mode by protocol.
A bridge is required when mixing Sm and Fm devices on the bus.
Ultra Fast Mode
UFm
5MHz
Write-only acceleration mode
Used with dedicated controllers and targets. Not compatible with other I²C modes.
Table 1: Frequency and features of each mode
2.4 Connection Topology
Any device connected to I²C is connected to two signal lines: SCL and SDA .
The connection is called a " multi-drop " connection. Each device is simply connected by "hanging" from two wires [Figure 5]. The number of devices that can be connected is limited by the " bus capacity ." The longer the signal line and the more devices connected, the greater the bus capacity.
Communication takes place between a "controller" and a "target". All communication is initiated by the controller.
In I²C, each transfer is performed one-to-one between the controller and the target. It is possible to intentionally have multiple targets have the same address, but from the controller's perspective, only "communication to one address" is possible [Figure 6].
The controller specifies the device to communicate with by using a target address and indicates the direction of data transfer. The controller controls all transfers (starting and ending, specifying the communication target and transfer direction, and outputting the clock to SCL).
It is also possible to have multiple controllers on one I²C bus. This is possible using an optional I²C function called " multi-controller ."
In this configuration, after one controller finishes a transfer, another controller can communicate. A bus arbitration procedure has also been established in case multiple controllers start a transfer at the same time. In a multi-controller configuration, all connected controllers must support this arbitration.
However, you will not see many systems with a multi-controller configuration. Many I²C controllers built into microcontrollers and other devices support multi-controller configurations, but most simple systems use a single controller. In this article, we will only consider the single controller case in order to explain the basics of I²C.
Figure 5 : Multi-drop connection
Figure 6: Communication to a single target address
3. Protocol
3.1 Required and optional features
The protocol determines how data is transferred. The I²C protocol has required and optional functions. The multi-controller mentioned in the previous section is an optional function. As mentioned there, we will not touch on optional functions here, but will only explain the required functions. The required and optional features of I²C are summarized in [Table 2].
Table 2: I²C Functions. Required/Optional (Excerpt from I²C Specification (Japanese version: rev5.0))
I²C communication generally has the following structure:
Start of communication
Data Transfer
End of communication
As an application of this, it is also possible to start the next communication without first ending the last communication ( repeat start ).
The data transfer section can transfer data from 1 byte to multiple bytes.
The first byte immediately after the start of a transfer is always transferred from the controller to the target, and specifies the target address and the direction of the subsequent data transfer (send or receive) . The I²C specification does not impose any particular restrictions on the number of bytes that can be transferred after the second byte [Figure 7].
When switching between sending and receiving data when communicating with the same target, or when communicating with a different target, start communication again and specify the target address and transfer direction again.
Figure 7: Basic structure of I²C communication
3.2 Data Transfer Unit
The basic unit of communication is 9 bits, with 8 bits of data followed by 1 bit. The data is 8 bits, MSB first. The last bit is an acknowledge bit , which is returned in the opposite direction to the data sent to confirm each communication. In I²C, transfers are always made in units of 9 bits [Figure 8]. Data is sent or received one bit per clock.
Data changes in sync with the clock. SDA can only change state (from LOW to HIGH or from HIGH to LOW) when SCL is LOW, and remains LOW or HIGH while SCL is HIGH [Figure 9].
Figure 8: A 1-bit acknowledgement is always returned for every 8-bit data transfer
Figure 9: SDA signal changes while SCL is LOW
3.3 Bus state: Start and end of transfer
The start and end of communication are notified by a start condition and a stop condition , respectively, which mark the end of the transfer.
As mentioned earlier, "SDA changes are only allowed when SCL is LOW," but this start/stop condition is an exception.
When SCL is HIGH, if SDA changes from HIGH to LOW, this is a start condition. Similarly, when SCL is HIGH, if it changes from LOW to HIGH, this is a stop condition [Figure 10].
Figure 10: Start and stop conditions
The state in which a transfer is in progress after a start condition is called " busy ," and the state in which no transfer is in progress after a stop condition is called " free ." A start condition is initiated in this free state.
The controller outputs the start/stop conditions and SCL. The 9-bit transfer following the start condition is used to specify the target address and transfer direction. The data is then transferred in one or more subsequent 9-bit transfers.
In addition to the start condition and stop condition, a " repeated start condition " is defined to separate transfers.
A start condition begins with the bus in a free state, but a stop condition must be passed before the bus can be put into a free state. If the controller is performing continuous transfers, it can omit issuing this stop condition. A repeated start condition starts the next transfer without going through a free state [Figure 11].
Figure 11: Repeated Start Condition
A repeated start condition occurs when a start condition is generated without a stop condition in the previous transfer. A repeated start condition is identical to a start condition in terms of functionality. In the following, the start condition will include a repeated start condition unless specifically stated as "repeated start condition."
The Repeated Start condition is provided in a multi-controller environment so that one controller can perform multiple transfers in succession while retaining bus ownership. This is because once the bus becomes free, another controller may start a transfer at that timing. By keeping the bus busy without using a Stop condition, the controller can maintain bus ownership.
From here on, we will refer to the unit from a (repeat) start condition to a stop condition, or from a (repeat) start condition to the next repeat start condition, as a " transaction " for convenience.
3.4 Transaction Structure
A transaction (Figure 12) always begins with a start condition. The data sent from the controller after the start condition specifies the target address and transfer direction.
Figure 12: Example of a basic I2C transfer and waveforms (write transaction example)
The target address is 7 bits of information used to specify the device to communicate with. Communication will occur with the device that matches this address (the I²C specification defines "10-bit addressing" as an option, but since 7-bit addressing is used in most cases, we will not mention this).
Following the 7-bit address is a bit specifying the transfer direction ( R/W ). If this bit is "0", it is a write transfer from the controller to the target, and if it is "1", it is a read transfer from the target to the controller.
The ninth bit after the seventh bit of the target address and one R/W bit is the acknowledge bit . This bit is a LOW signal returned from the target side. If the device specified by the target address output from the controller exists, the target device will output a LOW to SDA as an acknowledge bit. During this time, the controller outputs a HIGH, so if the target does not exist, SDA will remain HIGH. In other words, if the target exists, the acknowledge bit will be LOW, and if it does not exist, it will be HIGH. When this acknowledge bit is LOW, it is called ACK (acknowledge), and when it is HIGH, it is called NACK (not acknowledge).
The target address and transfer direction are output, and if an ACK is returned, data transfer will proceed. If the target does not exist and a NACK is returned, the transaction ends here (the controller issues a stop condition or a repeated start condition).
If the data transfer direction is write, the next 8 bits are transferred from the controller to the target, followed by a 1-bit acknowledge bit from the target to the controller.
If it is a read transfer, the controller keeps SDA in a HIGH state and reads the 8 bits output from the target in synchronization with SCL. This read transfer also always has an acknowledge bit. The acknowledge bit attached to the data in a read transfer is output by the controller. If the read transfer continues, an ACK is returned, and if the transfer is to be aborted, a NACK is returned.
ACK/NACK is important for I²C communication. This is because ACK allows communication to be performed while constantly checking the status of the other party. When a NACK occurs, the communication ends. The conditions under which a NACK occurs are as follows, quoted from the I²C specification:
The device specified by the target address does not exist on the bus.
The target device is currently performing some processing and is not in a state where it can communicate with the controller, so it cannot send or receive data.
The target device does not understand the data or commands received during the transfer
During a transfer, the target device cannot receive any more data bytes.
In a read transfer, when the controller notifies the target device that the transfer is complete
3.5 Write and Read Transactions
The data transfer direction is constant within a single transaction. Therefore, if you write something to a target device and then read from it, consecutive transactions will occur. For example, if you specify a register number for a target device and read from it, an example would be to perform a write transfer followed by a read transfer.
In this type of transfer, some target devices require a repeated start condition to separate transactions, while others may not behave as expected with a repeated start condition. This depends on the specifications of the target device, so you must be careful.
4. Reference materials
I2C Bus Specification and User Manual (Rev5.0 Japanese version)
I2C Bus Specification and User Manual (Rev7.0 English version)
NXP Community Blog: I²C Hardware Debugging
NXP Community Blog: I3C: The Next Serial Bus
NXP Community Blog: SPI Bus Overview
Interface March 2024 issue (CQ Publishing) : Special feature "Serial communication from scratch [UART/I2C/SPI with Pico]"
Transistor Technology Special No.161 "Measure, Measure, Measure Circuit & Technique Collection" Appendix: "Detailed Explanation of 2-wire Serial Interface I²C" - The above magazine article is an excerpt from this article.
First appearance:
Transistor Technology, October 2014 issue (CQ Publishing), "Basic Knowledge: Detailed Explanation of 2-Wire Serial Interface I²C," pp. 152-176
Interface Magazine, March 2024 issue (CQ Publishing), " Building I²C & SPI from Scratch ②...I²C Communication Standard," pp. 55-61 ← Updated and reorganized version of the above article.
For this blog post, I have excerpted, added to, and revised the section explaining the communication specifications.
Change history: 2025-02-03: First Edition 2025-02-04: "4. Added the blog post "I²C Hardware Debugging" to the "Reference Materials" section. March 5, 2025: Section 2.2 Open-Drain Output (Wired-and-Embed) corrected the reference figure number. 2025-11-30: Corrected a typographical error. 2026-04-03: Corrected the original entry.
=========================
We are currently unable to respond to comments in the "Comment" section of this post. We apologize for the inconvenience, but when making inquiries, please refer to `` Technical Questions to NXP - How to Contact Us( Japanese Blog) ''. (If you are already an NXP distributor or have a relationship with NXP, you may ask the person in charge directly.) The I²C bus is used for communication between microcontrollers/processors and peripheral devices.
Although this serial bus is so commonly used, I would like to take this opportunity to summarize its origins. communication standards Interface Japanese blog
查看全文
