understanding I2CWrite optional address parameter?

Hello,
I was experimenting with driving a PCF8547P 8-bit IO chip today with a PIC12F683

I tested it out by having it drive an LED bargraph

I was scratching my head over the "optional" address parameter within the I2CWRITE command.
I searched around and noticed someone applied the value of zero to that parameter, for the PCF8547P chip.
But I didn't think it would work - because the I2C protocol within PCF8547P datasheet does not call for that parameter.
So I figured the PCF8547P wouldn't respond.

I was surprised to find however it did work!
So I'm curious to know what is going on with that optional "Address" parameter.
Does the I2CWrite function ignore it when it is zero?
If the I2CWrite function actually does send a zero - how is it that does not mess up the PCF8547P's protocol?

Thanks
dw

Attached is also a screen shot of one of the I2C transactions.
I was surprised to see two read transactions followed by one write transaction.
Especially because there is no IC2READ occurring in the code.
I'm simply writing one value to the IO chip.
So I wonder if the chip is programmed to return the two READ transactions - or is PBP3 doing that as part of the IC2WRITE function?

PCF8547p/t/a is an unusual situation having only one register to read or write from, the chip cares not how many reads or writes you squeeze into one transaction.
the final result is the last byte written or read.

all i2c read transactions start with a write transaction sequence to set the register to read from if necessary a PCF8547p/t/a ignores this action.

to make any sense of what you allege without the code to demonstrate it is near impossible

Quote:

---

So I'm curious to know what is going on with that optional "Address" parameter.
Does the I2CWrite function ignore it when it is zero?

---

The "address" is just another one or two data bytes (depending on the data type used) sent before the actual "data".
Typically it's used for eeproms where you need to send an address parameter, or a register number.

The PCF8574 only has a single 8-bit register and doesn't require anything but the data. If you send multiple bytes to the device it'll
set the output port multiple times. For example, if you sent $00, $55 it would set all the outputs low before setting the port to $55.
So, setting the "address" to 0 will do the same thing.

I can't explain the read. It's certainly not being sent by the PCF since it's a slave device.

Thanks!

Here is the code:
-----------------------------------------------------

mainloop:
for B0 = 0 to 255
I2CWRITE SDA, SCL, $40, 0, [B0]
pause 500
next B0

pause 1000

for B0 = 255 to 0 step -1
I2CWRITE SDA, SCL, $40, 0, [B0]
pause 500
next B0

goto mainloop
End

My guess is - since the PCF chip isn't doing the READ transaction - it must be built into the IC2WRITE function.
Just curious
Thanks

thats not a complete program ,its a pointlless snippet

this is a program

Code:

---

;pic16f1825
DEFINE I2C_SLOW 1

#CONFIG
            __config        _CONFIG1,    _FOSC_INTOSC & _CP_OFF & _WDTE_OFF  &  _PWRTE_ON  &  _MCLRE_ON  & _CLKOUTEN_OFF
              __config      _CONFIG2, _PLLEN_ON & _LVP_OFF
#ENDCONFIG
 


define OSC 32




trisa=%11011111
trisc=%11111110


ANSELA = 0
ANSELC = 0
OSCCON = $70


OPTION_REG.7=0
wpuc= %00011000


SDA        VAR PORTc.3      ; I2C Data pin
SCL        VAR PORTc.4    ; I2C Clock Pin
pcf_Addr CON $78
led        VAR latc.0
leds var byte
b0 var byte


Main:


for B0 = 0 to 255
I2CWRITE SDA, SCL, pcf_Addr, 0, [B0]
pause 5
led=!led
next B0


pause 1000


for B0 = 255 to 0 step -1
I2CWRITE SDA, SCL, pcf_Addr, 0, [B0]
pause 5
led=!led
next B0
led=!led
goto Main

---

this is how it looks on a logic analyzerAttachment 9008

and this is a trace , is shows no signs of what you claim

Thanks Richard
Interesting how my analyzer shows two READ transactions following each WRITE transaction - and your's apparently does not.

Quote:

---

Interesting how my analyzer shows two READ transactions following each WRITE transaction - and your's apparently does not.

---

there is no apparently. its what should and does happen.


more interesting is that your analyser does not even come close to reflecting what your "snippet" should reproduce.

either your analyser is defective/miss used or the "snippet" is not what is being measured.

I think its best for me to drop this conversation.