Questions about I2C slave

[toptensoftware]

Where can I find some more information about how i2c slave works? For example:

• I'm looking at the i2cping example, and it looks like the slave is polling for updates. Is it possible to get an interrupt notification instead of polling?
• If a read asks for more bytes than available does it block until that many bytes have been read, or does it return immediately with whatever is currently available?
• Is there any buffering on the received data and if so what size is the buffer?

[rsta2]

The Circle I2C slave driver is simple polling driver. The I2C slave peripheral in the Raspberry Pi supports interrupts, but this is not used here. When more bytes are requested than are actually sent by the master, the received bytes are returned immediately in the buffer with the byte count returned by Read() smaller than the given buffer size. The peripheral has a FIFO. I guess it can buffer 16 bytes, but this is not specified in the hardware specification, which is here (page 160-171).

[toptensoftware]

Thanks Rene, that's useful info. Hopefully polling will be enough for now.

[rsta2]

Did this work for you or do we need an interrupt driven I2C slave?

[toptensoftware]

Hey Rene,

I haven't had a chance to look at it properly yet (I've been stuck trying to get a DPI LCD display panel working). If it's not too hard to implement I'd almost certainly use it. My main concern about polling it is I'll be running an OpenGL render loop too which I think throttles the loop to the frame rate - not sure if that'd be fast enough for polling i2c.

Brad

[rsta2]

Hi Brad, OK, let me know, when polling I2C is not fast enough.

Rene

[toptensoftware]

Hi Rene,

I'm finally getting around to integrating this with my OpenGL render loop and have hit a blocking issue - it seems CI2CSlave::Read() blocks if nothing has been received. I've tried just reading a single byte and it doesn't return until the first byte is received.

How do I poll and just read what's available and return immediately if there's nothing?

Brad

[toptensoftware]

fwiw, not sure if this correct but I got this working by replacing the first while loop in CI2CSlave::Read with this:

	while (nCount > 0 && (read32 (ARM_BSC_SPI_SLAVE_FR) & FR_RXFE) == 0)
	{
		if (read32 (ARM_BSC_SPI_SLAVE_RSR) & RSR_OE)
		{
			nResult = -1;

			break;
		}

		*pData++ = read32 (ARM_BSC_SPI_SLAVE_DR) & DR_DATA__MASK;

		nResult++;
		nCount--;
	}

[rsta2]

Hi Brad, yes, you are right, it blocks and there is no way out with the current implementation. Please give me two days for an update, which is also in sync with sample/16-i2cping.

Rene

[toptensoftware]

Thanks Rene. No rush as I can work with my temp hack until you get it sorted.

[rsta2]

I added a timeout parameter to CI2CSlave::Read() and CI2CSlave::Write() as a more generic solution. When you specify TimeoutNone as 3rd parameter, you should get the same behavior, as suggested by yourself. By default the methods will block, when no transfer occurs, which is similar to the previous behavior. It's on the develop branch.

[toptensoftware]

Awesome, thanks Rene. I'll check it out but might be a few days... I've got some other high priority work that's popped up but hope to get back to this soon.

[rsta2]

Thanks Brad for info. No problem.

[toptensoftware]

Hi Rene,

I'm back working on my bare metal Pi project again and I'm having issues with I2C - receiving corrupted packets and occasional lock ups. Some questions:

• How hard would it be to update CI2CSlave to support an interrupt mode that moves incoming data to a temporary buffer to make it more resilient in case the program is busy and doesn't poll quickly enough?
• Is there any way I can check if there's been I2C data dropped/lost and/or monitor the state of the I2C port?
• Are there any other timeouts or control over the slave mode? I2C lockups are usually because the slave is holding the data line and the master can't get control again. I think that might be happening in my case and wondering if there's anything I can do to release it. I'm still investigating what's causing the lock up, but it'd be good to have a way to force the slave to let go on a timeout (if possible).

Anything that can be done to make this more reliable would be much appreciated (at the end of the day I need something rock solid).

Brad