How to end sending data over I2C by Slave or Master?

Question

Let us say a Slave or Master is sending multiple bytes to the receiver on I2C bus and the number of bytes is not defined before hand. So then how will the sender tell the receiver that it has no more data to send?

So far what I understand is that for the case when the sender is Master then it sends a NACK to tell the Slave (Receiver) that there is no more data to send. And after sending NACK then it sends the STOP condition to finish the session.

But I wonder how does this handshaking takes place between a Master and Slave when the Slave is sender and the Master is receiver and only the Slave (sender) knows when there is no more data to send to the receiver?

Answer 1

But I wonder how does this handshaking takes place between a Master and Slave when the Slave is sender and the Master is receiver and only the Slave (sender) knows when there is no more data to send to the receiver?

This isn't supposed to happen. i2c is a very defined protocol and each slave device should be known to each master. Typically, the master requests the slave to transmit, and either the message size is fixed, the message is sequential, or the message includes how many bytes will be sent.

1. Master writes a register address, then master switches to read and the slave sends a byte. That's all the master wants, sends a stop.

2. Master writes a register address, then master switches to read and the slave sends a byte, then the master reads again, so the slave sends the next byte (or same byte). The master reads how ever many it wants, arbitrarily, then sends a stop.

3. Master writes a register address, then master switches to read and the slave sends a byte. That byte tells the master how many bytes that register should have. Master reads and slave sends that many, then master stops.

All communication is controlled by the master. The slave does nothing the master doesn't want it to do. The master controls the speed of the clock (clock stretching not withstanding) and how many bytes are read. At no time should the slave try forcing the data line when the master did not tell it to. The data structure should be known before hand.

Answer 2

Those are the two options.

If slave receiver does not accept more data it can NAK the byte, but master is still responsible for sending the stop condition.

For a slave transmitter, it can't signal anything to stop, it must be known beforehand, or it could be encoded in the data, e.g. text string is terminated with a zero so slave can transmit zeroes until master stops.

Usually, this is rare and there is a known protocol so master must always know beforehand how many bytes it will read or write in a single transaction, even if it means transferring first a fixed size header between devices how much to transfer.

Answer 3

Let us say a Slave or Master is sending multiple bytes to the receiver on I2C bus and the number of bytes is not defined before hand. So then how will the sender tell the receiver that it has no more data to send?

If Master is the sender, then he knows how many bytes have to be sent. Master will signal the end of his data transfer by sending a STOP condition after sending the last byte, and terminate the transaction.

Note that Master can do this anytime. Slave can send NACK to say that it doesn't want to receive anymore data. But only Master decides whether to stop this transaction.

But I wonder how does this handshaking takes place between a Master and Slave when the Slave is sender and the Master is receiver and only the Slave (sender) knows when there is no more data to send to the receiver?

If Slave is the sender, Master should beforehand know how many bytes have to be received. Master will signal this by sending a NACK after receiving the last byte so that the slave will no longer drive the SDA line. Master can now initiate a STOP condition and terminate the transaction.

Have a good read here : TEXAS i2c

Answer 4

I'm going to digest your entire post little by little...

Let us say a Slave or Master is sending multiple bytes to the receiver on I2C bus and the number of bytes is not defined before hand.

But it should be defined. If random information was being sent or received, you'll never be able to interpret it.

So then how will the sender tell the receiver that it has no more data to send?

The manufacturer determines how many bits it needs to receive from the slave. The master is typically written by some logic device like a microcontroller, CPU, etc.

So far what I understand is that for the case when the sender is Master then it sends a NACK to tell the Slave (Receiver) that there is no more data to send.

No, not entirely right correct. A "NACK" occurs when the master doesn't "hear" anything back from the slave after it sends this bit to the slave. It's like being on the phone and saying, "Hello, are you there?"

But I wonder how does this handshaking takes place between a Master and Slave when the Slave is sender and the Master is receiver and only the Slave (sender) knows when there is no more data to send to the receiver?

Your definition of sender and receiver is skewed. Both the master and slave act as both a sender and receiver. The master can both send and receive, depending on write or read operations respectively.

---

Helpful advice: Consider reading any I2C slave datasheet. Look for the keyword, "message". This is the information that the master sends to the slave.

Picture from here... not my picture.

The master should be programmed to read the same length of the address frame as the slave, which is defined by the datasheet of the slave. You also may be able to set an address of a slave but usually not by much. This will help addressing conflict if two slaves share the same address.

---

Here's an example of a part that I actually just recently worked with, it's an ADM1276 hot-swap controller. It abides by the PMBUS specifications but the I2C topology still applies. It tells you the interactions of master and slave when you're sending, receiving, reading, and writing bytes.

Answer 5

There isn't anything in the i2c protocol that solves this problem. You can make it work, but you will use some software to do it. Since i2c was designed for hardware communication, usually involving fixed size registers, nothing was provided to handle variable-length data. I found this out myself and have had to solve the same problem you are considering.

Since the master controls everything, all the slave can do is send it clues about how much data is has to send. What has worked best for me is to have the slave send the length as the first byte. Then the master knows how many bytes it needs to ask for.

Answer 6

The protocol itself does not allow such action, but it is nothing that cannot be solved with programming.

Two possible options possibly:

1. That the teacher first requests a value in this integer case (less than 255) and this will be the size of the data that you will send later on the next call you make.

2. If you have knowledge of the maximum length that the data to send will have, take this as a reference, convert it to an array or string and add a specific character that you are going to take to mark where your data ends and in the master you convert again in the type of data you are using. With the smallest data, fill in the rest of the string with your special character and voila, you will always send a string with the same size.