i2c Slave addressing

[Guest]

Hi,
WHOOO!!! I have an issue with slave addressing in the I2C interface.

MASTER: Philips P87C51RC+4N
SLAVE: PIC 18F2520

The data sheet states that in an I2C interface when the master sends for an I2C request the address the master sends to the SSPSR register is matched with the address in the SSPADD( The register where the address of the slave is saved) register.
The value of the register SSPSR<7> is compared to the value of the SSPADD register.

In my case the Master has already been coded, and its code cannot be changed. But I can change the salve code in the interface. In the pseudo code of the I2C interface by the master I noticed that the master uses only bits <7> for an address match. And manipulates the logic of the bits <3> in order for the slave to know what information the master requires from it.
In other words, instead of sending the slave address <7> for an address match and then sending another address <7> as a control byte to let the slave know what it needs, the master is combining both by using the 4MSBs as the address of the slave and the 4LSBs as the control.
Since the master is talking only to one Slave, I read on the data sheet that it is possible for the user to interrupt on start and stop bits from the master. I was wanting to know if there is anyway to make the slave send an ACK on a start from the master, and then see the first byte sent by the master and decide what to do next. Because if I wait for address matching, it would not happen as the master sends only the 4MSBs same, but not the other 4 bits in the byte.
Or is there any other way to approach this issue!!

[libor]

I would try to bypass the slave's address-matching hardware:
- enable the interrupt for the start condition (SSPxCON1.3 = 1)
- read the first incoming byte (the slave address, whatever it is) in the interrupt handler routine waiting for it to arrive and reading the SSPBUF, and act upon its value.

[Mark]

If the master looks for an ACK from the slave and doesn't get one and then tries the exact same message again much like you would do to poll the status of an eeprom then you could make it work by looking at the start and stop interrupts. If you get a start and stop interrupt without any data, then you can assume that the message was not for you. That is that the address does not match. If you immediately change to the other address and the master resends the message, you should receive it just fine.

[rnielsen]

If the Master is looking for an ACK after it sends out a Start signal then it is not I2C compliant. The 87C51 is another type of micro-controller that has it's own code embedded inside of it. Without knowing what the 87C51 is expecting it's hard to know how to respond to it. An ACK should only be sent on the successful transmission or reception of a byte. The I2C protocol has specific patterns that should be followed or the I2C bus will puke all over your proto-board.

If the 87C51 micro-controller was programmed by somebody else you should find out what it expects from the Slave.

Sorry for not being much help

Ronald

[Guest]

I have an issue with slave addressing in the I2C interface. I have only a single master and a single slave.

MASTER: Philips P87C51RC+4N
SLAVE: PIC 18F2520

The situation is that the Master queries the slave with 3 different addresses. And the same slave is supposed to respond with different data depending on the address the master queried with. I cannot change the code in the master.

So the situation is like the slave has 3 addresses. Obviously this will cause problem with address matching.

I wanted to know if there is any way to try to get the data from the SSPSR reg into the SSPBUF without as address match??

I tried the suggestion to bypass the slave's address-matching hardware:
- enable the interrupt for the start condition (SSPxCON1.3 = 1)
- read the first incoming byte (the slave address, whatever it is) in the interrupt handler routine waiting for it to arrive and reading the SSPBUF, and act upon its value.

The problem I faced with the above suggestion that I did go into the interrupt, but for some reason didn’t come out. I think it was because I went into the interrupt due to a (start I2C) from the master, but the hardware could not match the slave address so it did not send an ACK, and then the slave never received a (stop I2C) from the master, so it never came out of the interrupt. That’s what I think!! I may be wrong.

[libor]

The problem is (I think I was wrong about) that the SSPBUF register never gets written from the SSPSR if there is no address match after the start condition. (I thought that only the interrupt is that does not get fired)

- How fast is the master transmitting ? 100kHz ? Does your PIC have to do other thing beside emulating 3 slaves ? ..you could try a bit-banging solution written in pure software. ...or hibrid one.. address matching done in software, and then replying using the hw.

- another thought: you can loop back two of the PIC's other ports into the PIC's i2c pins and create an another 'master' in the bus (in software of course). This software would prefill the i2c hw address matching circuit with a proper matching dummy address and nothing more, so your PIC would wait for (what it thinks) the rest of the packet and treat all subsequent bytes (coming from the real master) as pure data, so you'll be able to read all bytes, including the first one, the address. ...though I don't know what happens after the repeated start condition.