Hey everyone,
I'm trying to wrap my head around the I2C protocol and the intricacies of data transfer between the master and slave devices.
Specifically, I'm confused about when the master transfers a bit to a slave device in terms of clock high, clock low, rising edges, and falling edges. Could someone break down the process for me in these terms? I'd appreciate any insights!
Most (all) i2c devices have the breakdown on the i2c protocol as part of their datasheet.
In a nutshell, SDA (data) changes state while SCK (clock) is low and must be valid on the rising edge of SCK.
Do you have two Arduinos (UNO/NANO/MEGA)? If yes, then we can execute a simple data exchange program/skecth in ordder to get the answers of your queries.
Here ya go, direct from NXP. All the detail you could ever want.
UM10204.pdf (733.4 KB)
I have only one mega256.
I'm interested in understanding the interplay of clock high, clock low, rising edges, and falling edges when the master sends a single bit that the slave receives. In this case, I think master transfers the bit (on the falling edge, high to low transition of clock ) and when the slave reads the bit (on the rising edge, low to high transition of clock ). Any insights into this would be greatly appreciated!
The NXP (formerly Philips - the inventors of I2C) document is the definitive source for that.
See Post #4.
I have gone through that documents
I think In this scenario, the master transfers the bit during the falling edge (high to low transition) of the clock, and the slave reads the bit on the rising edge (low to high transition) of the clock.
I just want to clarify that my above understanding is correct ?
I2C is a byte oriented protocol which means that 8-bit data are sent/received in ONE GO. It is a synchronous transmission; where, a data bit is pushed-in into Slave and pushed-out from Slave in response one of four parameters of the SCL signal (Rising edge, HIGH, Falling edge, LOW). The following diagram (Fig-1) may be helpfult for you.
Revised version of Fig-1:
Yes, it is indeed that simple. The I2C bus was created around 1980. Think in 1980s logic chips with shift registers. Each clock pulse by the Master shifts the shift registers one step (in both the Master and the Slave). The ACK on 9th clock pulse latches the shift registers with new data to be shifted out or the received 8-bits of data are used.
The documentation is exactly that, but de signals are defined in such a way, that it is hard to see the shift registers and the latching at the 9th clock pulse.
There are some rules for the timing that make it a little more complex. After the SCL has fallen, the SDA is supposed to hang around at its level for a short time.
If you understand this, then let's go one step further:
When writing a software I2C library, then the level of SDA can be read just before the falling edge of SCL, gaining extra time for a steady SDA level.
I'm finding this diagram very helpful in understanding I2C data transfer. Kudos to you for contributes! I do have a specific query – I'm curious about the source of the diagram. Was it created by you ? Can we also get a diagram illustrating the process when the master reads data from a slave?
Thanks in advance for any insights!
The source is the data sheets of ATmega32A/ATmega328P but the drawings are tailored to meet my taste!
For your information: Before I came to know in 2017 that Arduino UNO exits, I had been programming the TWI/I2C bus using assembly language (AVR Studio 4) for ATmega32A (predcessor of ATmega328P of UNO Board).
I have checked my database, but I cannot find any diagram for that operation. However, it can be easily made based on the digarm that I have provided.
I would suggest that you collect at least one Arduino UNO. Excute some examples for I2C-based data exchange between MEGA/UNO, observe the result and then it will be easier for you to make meaningfull discussion on this issue as the codes of Arduino Platform are of High level and many things are insulated to the user/programmer.
I am confused between below two statement. I think first one is incorrect and second is correct as per diagram you posted. Please clarify @GolamMostafa
Clock Edges: Data is transferred on the edges of the clock signal. There are two types of clock edges: rising edges (transition from low to high) and falling edges (transition from high to low).
Data Bit Transfer: Data bits are transferred during the clock high period, just before the clock transitions from high to low (falling edge). The data line (SDA) is allowed to change while the clock line (SCL) is high.
Data is not transferred just before the falling edge of SCL. That is an extra possibility that a software implementation can do, but not in hardware.
You really have to go back to the 1980s.
Logic chips are slow. The I2C bus is not only for fast processors, but also for slower chips.
When the SDA is put into a shift register at the rising clock of the SCL, then there are delays. Suppose it takes a microsecond for the SDA to be captured after the rising edge of SCL, and another microsecond has to be waited for safety before SCL can drop low, and the same at the low level of SCL, then a clock cycle takes 4µs, resulting in I2C clock of 250kHz. A lot of extra margin is needed for the slow rising signals (because of the open-collector output and the pullup resistors) and then you have the default clock of 100kHz.
Refer to Fig-1 of post #9:
1. You are right that the phrase "data change" in Fig-1 of Post #9 is confusing; it should be "data is changing". I will revise my diagram. Thanks for the meticulous observation.
2. At the beginning of 3rd cycle CLK-L Period starts), data bit on SDA line is changing (not yet has changed) from 0 to 1. After CLK_L period, the data is stable on SDA line. According to this diagram, the data bit is latcehd into receiver during HIGH period (CLK-H) of SCL signal. The timing diagram of Fig-2 (extracted from data sheets) also supports the said proposition.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.
