i2c clock stretching

[YahooArchive]

G'day,

I've had a few intermittent issues with I2CIN (using the C library,
haven't tested it in Basic). As I've only been driving an SP03 voice
synthesis unit so far, it hasn't really been an issue.

According to the I2C spec, if the slave needs a moment to catch its
breath, it may pull the clocking line low. The master should wait for
this line to be released before clocking in data. Not something that
happens with EEPROM, but smarter devices can do it.

Does the I2CIN routine support this?

The SP03, whilst speaking, will contain 0x40 in its status register.
This occasionally is read in as 0xA0 (I don't recall ever seeing
0x20). Likewise, when it has finished speaking, the register is set
to 0x00. Sometimes I2CIN reads 0x80.

I suspect that its reading in a bad high bit whilst the clock line is
low, and dropping off the low bit.

It isn't a major concern at the moment, as I just <<1 this result (and
I don't care about the high or low bits of the data). However, with
the Micro Mega FPU which I would like to use on the next project, this
wouldn't be a viable solution.

Has anyone else had this occur with other I2C devices?

Cheers,

Matt Power.

[YahooArchive]

>The master should wait for
> this line to be released before clocking in data.
> Does the I2CIN routine support this?

I2CIN code is currently shared between BASIC and C, and it does not
support clock stretching by a slave.

Have you tried setting I2CSPEED to a slower rate?

I don't know how common this is with I2C devices. It could be added
at least on a byte basis without slowing down the transfer. If it was
done on a bit by bit basis, transfers would probably not occur at 400Kb.