Confused about how this I2C read works

[Chet T16]

I have an i2c master which writes to a slave (controlling the display) and reads from the same slave getting the button presses.

In idle mode the masters reads every 0.5 seconds or so and receives the following

S 01000111 0 00000001 0 00000001 0 P
Read from address: 0x23 Number of Bytes: 2
Byte 1: 0x01
Byte 2: 0x01

Pressing a button causes a read instantly giving similar to below

S 01000111 0 00000100 0 10000010 0 10010001 0 00000000 0 00000100 0 P
Read from address: 0x23 Number of Bytes: 5
Byte 1: 0x04
Byte 2: 0x82
Byte 3: 0x91
Byte 4: 0x00
Byte 5: 0x04

There is a third line in addition to SDA and SCL which is pulled low during read and write operations, i thought perhaps that the slave was pulling this low when data was available but having disconnected the master and watched this third line it is going low for three 6ms pulses every 0.5 seconds. Pressing a button has no affect on this.

I have successfully managed to write to the slave but not read. I have tried to read both 2 and 5 bytes when the third line goes low. Reading 2 will give me 0x01 0x01 as above but trying 5 will just give me 0x01 0x01 0xff 0xff 0xff with button presses having no affect on  the output.

Any clues how the master might be telling when there is data to be read or what i could try?

Thanks

[Chet T16]

Further testing shows that its the slave that decides when to be read from, the master holding the line low when writing and the slave doing the same for reads.

Using the arduino wire library as read requests need to specify the number of bytes, i this normal practise? Should the master be able to open a request and the slave decide when to stop?

[shebu18]

Can you give us the model of the slave and master? Exact name. In I2C you have only 2 line, not 3. 3lines sounds more like some sort of SPI.

[richcj10]

It really depends on the device. There are EEPROM devices that allow consecutive reads from the device w/o requesting the data.

What chip is it? That would tell forum members more information.

[richcj10]

Can you give us the model of the slave and master? Exact name. In I2C you have only 2 line, not 3. 3lines sounds more like some sort of SPI.

It could be a interrupt....

[Chet T16]

I'm calling it i2c as not counting the third line it is the same and the display will work with only the data and clock connected.

I don't know the models as I haven't taken them apart (these are in my car) I only have access to the wiring between them.

[caroper]

"I'm calling it i2c as not counting the third line it is the same and the display will work with only the data and clock connected."

You can't just arbitrarily call it anything based on the number of lines, you may as well call it RS232 as that will work with only 2 lines as well.
Based on your description though I would have to agree that you are using SPI not I2C, as SPI also requires  Clock and a Data lines. The 3rd or more lines in SPI are Chip Select Lines when you have more than one device on the bus.

Whilst electrically the same SPI, I2C and RS232 are all Software Protocols as well as a Hardware Standard.
To really know what is happening you need to know what the Protocol is and therefor what Signals and Timing to expect on the lines, hence we can't help you unless you state the Protocol used.

Cheers
Chris

[Chet T16]

When i sat its the same i mean the protocol is the same, aside from the 7kHz clock speed which i put down to being used because of the distance between the devices.

I'll take the slave apart and see if i can find anything inside

[Chet T16]

Inside the slave is some Sagem ic (AFRHEUT0200 HD6433834822H) that isn't throwing up any results on google and a few other bits - voltage reg, inverter, discretes etc

[richcj10]

Is this in a car?
Could it be CAN?

[Chet T16]

Yes, its in a car. It is the radio (master) and the display/wheel controls(slave). I tried doing this on my old car which had a very similar setup (3 wires, 2 of which followed the i2c protocol)

The car is a 2002, it has a primitive CAN bus but the radio setup is isolated. The later versions of my car did switch to CAN for the radio.

[richcj10]

It is probably CAN. It may not be at CAN voltages. That means it is not using transceivers.  Do you have a scope? Logic analyzer?

[AndreasF]

Further testing shows that its the slave that decides when to be read from, the master holding the line low when writing and the slave doing the same for reads.
...

That doesn't really sound like 'slave' behaviour (unless I misunderstood your description). You can have multiple masters in an I2C bus, if what you have is indeed an I2C protocol.

[Chet T16]

It is probably CAN. It may not be at CAN voltages. That means it is not using transceivers.  Do you have a scope? Logic analyzer?

Yes, both. 5v logic levels and the logic analyser decodes it as i2c. Writing works fine using a standard i2c library (only modified to use the 7kHz clock)

[Chet T16]

Further testing shows that its the slave that decides when to be read from, the master holding the line low when writing and the slave doing the same for reads.
...

That doesn't really sound like 'slave' behaviour (unless I misunderstood your description). You can have multiple masters in an I2C bus, if what you have is indeed an I2C protocol.

When i posted originally i wasn't aware that it was the slave (i'll stick with that term for the minute!) that was pulling the third line low. It does appear the the reads are initiated from the master following the i2c protocol but the timing of the reads is determined by the slave.

The thing i find unusual is the varying number of bytes sent from the slave as it was my understanding that the master determined the amount read whereas here it would have no prior knowledge of whether it had five bytes to read. I don't think this will matter for me reading button presses anyway but i am curious.

[AndreasF]

Well, the first byte that's being sent (by the slave) seems to indicate the number of bytes that are available to read (from the slave), so all the master needs to do is send the slave address in read mode, wait for the first byte from the slave, and continue to read according to this first byte.

[Chet T16]

Having looked into the library I think i see where I've gotten mixed up. With the arduino you start a read specifying the address and number of bytes. These are then read from the buffer. I was mistaken in thinking the master sent the number of bytes to the slave.

Yes the first byte returned will give me an indication of whether I have a button press to read.

[free_electron]

if they use 3 wire it could be C-Bus... that is almost i2c...

[ve7xen]

Is this maybe an (ab)use of I2C clock stretching? The master could be initiating the read immediately after having received some data, with the slave stretching the clock until an event happens, when it sends the requested data to the master. This feature is designed to allow the slave to throttle commands if the master is sending them too quickly for it to handle, but I suppose it could be used as a crude form of interrupt as well.

I'm not sure if the AVR TWI peripheral supports clock stretching (check the manual, this is an oft-omitted feature), but I'd bet the Arduino bit-banged library does not. I believe Peter Fleury's bitbanged I2C library does, however.

[amyk]

Inside the slave is some Sagem ic (AFRHEUT0200 HD6433834822H) that isn't throwing up any results on google and a few other bits - voltage reg, inverter, discretes etc

I think you misread the part# as that is probably the HD6433834S - Hitachi (now Renesas) H8 microcontroller. The datasheet does not explicitly mention CAN or I2C but there is a UART peripheral capable of different transfer modes. Or they could be bit-banging I2C/CAN...

[Chet T16]

I done some more testing, after a write the slave will pull the third line low waiting for a read. If it doesn't get one it will release the line and try twice more. If i initiate a read when its pulled low i can read the data, either the 2 or 5 bytes depending on whether the buttons are pressed. Strangely although reading them fine the arduino is is not sending an ACK for the last byte which causes the slave to try to send everything again (twice more, as above) so if i read a button press i will actually see it three times.

Inside the slave is some Sagem ic (AFRHEUT0200 HD6433834822H) that isn't throwing up any results on google and a few other bits - voltage reg, inverter, discretes etc

I think you misread the part# as that is probably the HD6433834S - Hitachi (now Renesas) H8 microcontroller. The datasheet does not explicitly mention CAN or I2C but there is a UART peripheral capable of different transfer modes. Or they could be bit-banging I2C/CAN...

I didn't take the display apart again (it has one of thos super thin ribbon cable things attaching the LCD that i don't want to break) but the package seems to match up. Good spot!

[Chet T16]

Some logic analyser screen grabs

Here is a read with the original master and slave



And here is one with me as master

[amyk]

Since this might not really be I2C you may be violating some timing requirement.

[richcj10]

Some devices don't care or want to see the NAK.
Other IC's really care about seeing the ACK. 
Try that first.

[TerminalJack505]

The Arduino library will send a NACK when it has received the last byte.  This is normal.  It's supposed to tell the slave that the master is done reading. 

You might be able to emulate the behavior you are seeing by calling Wire.requestFrom() with a quantity parameter value that is larger than the number of bytes you actually expect.

If that doesn't work AND you actually need that behavior then you might just try bit-banging the I2C bus yourself.

The attached ZIP has the code from a simple little project I did with an ATtiny2313, which has no native I2C support.  I'm pretty sure the code for bit-banging the I2C bus was taken pretty much as-is from an Atmel app note.  I likely just wrapped their code in a C++ class.