[General] i2c and reading a variable number of bytes from a slave device

[dxpwny]

My question concerns the i2c protocol. I am using two microcontrollers, one is always the master, one always the slave. There is no i2c peripheral involved, just my two microcontrollers. I am familiar with the master/slave concept and the use of the read/write bit, etc. So, my description below is a bit simplified.

When a master initiates a read operation, is it possible for the slave to determine the number of bytes that it will transfer ?

In all the i2c projects I've done, the master reads a predetermined number of bytes from the slave. In my current project, it is conceivable that the slave may have a variable number of bytes available for reading.

When the master performs the read operation, I need the slave to send all of the data - however, its length may vary from one read to the next.

My understanding of the i2c protocol tells me that the only way for me to do this is to have the master perform an initial read operation, and the slave would always reply with one (or two) bytes which indicates how many bytes it has. Then the master would initiate a second read of exactly that number of bytes.

In other words, the master would send the slave address, and a "register address". The slave, knowing that that specific "register address" is being read, would respond with the number of bytes it has. Then the master would initiate a second read operation, sending the slave address, then a different "register address". The Slave then outputs the data as the master clocks it out, the master terminating the transfer after the count is reached.

Is that the only way to handle a slave which may only have a variable number of bytes available ?

 

[betwixt]

That is probably the most versatile method but if there is a unique data byte that isn't normally used you can make it recognizable as a terminator. Basically put it at the end of the wanted data then just keep reading until you find it.

Brian.

 

[KlausST]

Hi,

In my current project, it is conceivable that the slave may have a variable number of bytes available for reading.

This sounds like some streaming data or dota coming from a FIFO.
If streaming: I2C is not meant for streaming data, but for sure it will be possible to achieve, somehow.

If FIFO: then either by an "END_OF_DATA_BYTE" or the master first read (maybe the first byte determines the count of following data bytes to read) how many bytes are available at the salve. As you already wrote.

You are free to use another signal in parallel to the I2C lines to show whether data is avalilable or not.
Maybe with a dedicated threshold level. So that it tells "there are at least 8 bytes in buffer". So the master may read 8 bytes (a constant number of bytes)

Klaus

 

[dxpwny]

Actually I'm just writing code I'll reuse a few times in various i2c periperals such as a keypad decoder and an IR remote tranciever. The keypad decoder would be fixed length, but the IR tranciever might be 4 to 10 bytes at a time, so I'll implement the two step process. First read the byte count, then do a read-array for that many bytes.

 

[FvM]

The appropriate method is commanded by the slave. If the slave uses a "number of bytes available" register, you should read it.

 

[KlausST]

Hi,

I'd personally would avoid two "different accesses.
Two accesses needs the implementation of two commands. This is more software effort in both master and slave.
And it makes access slow in case of high traffic becazse you need
(Start, Slaveaddress, command, readByte) twice

I'd rather send [valid/available bytes] as first byte, then [dataBytes], or [dummyBytes]

So you are able to do all in one access, no need for two different accesses.
Example: there are 6 bytes available at the slave:
So the data returned by the slave are:
[6] [data0] [data1] [data2] [data3] [data4] [data5] [dummy] [dummy] .... (as many as the master requests)
So the master is most flexible.

It may read a fixed count of bytes (adjust byte count to max expectable datarate) let's say "8".
[6] [data0] [data1] [data2] [data3] [data4] [data5] [dummy]
...and dismiss the dummy byte after parsing byte count.

Or dynamically adjust byte count:
Read first byte
Read second byte (maybe valid, maybe dummy), while parsing first byte and deciding how many additional data to read.

... just as idea

Klaus