PCF8575C: When is a WRITE 0xFFFF necessary to use this part as input pins?

A 0 pin strongly drives low. A 1 pin weakly drives high. So to be able to read the external voltage at a pin, it must be in the 1 state.

This means that you need to do the write only once. (Or not at all, because 1 is the default state after power up.)

Thank you Cemens.

That part I already understood. Unfortunately, see my pseudo code, I already write the pins high before reading and cannot read subsequent words after the first one.

I've been digging into the data sheet and as far as my limited knowledge on logic schemes goes, the only way a pin (page 12 of the data sheet outlining the binary logic circuit of one P-port) can go low again, is if one writes a 0.

In my case, somehow the pin goes low "by itself". So we can consider this an anomaly and indeed writing a 1 once  should suffice for multiple reads?!?.

In that case, I should try to get my hand on a logic analyser.

Apologies for misspelling your name Clemens, can't edit a reply.

What you describe should not happen. Please show the write/read_PCF functions.

It is part of a larger code, I quote the entire program here, in line 30 the essential line is marked. Goal is to activate a relay when a corresponding radar sensor detects motion. Motion pulls the PCF8575C to ground by an optocoupler (817C). The code below works like a charm, running on a Raspberry Pi Zero W.

When I move the essential code line to before the While loop (ie. write only once), in no time all relays become active, as if the 0x20 PCF8575C loses bit by bit the high level. Only two radar detectors are connected, the other P ports are unconnected. Behaviour is the same when I swap the PCF8575C for another one, ie. the chip is not broken I think.

#!/usr/bin/env python3

from smbus import SMBus
import RPi.GPIO as GPIO
import time

INTERRUPT_GPIO = 17

i2cbus = SMBus(1)
i2cradar = 0x20
i2crelay = 0x21

hiByte = 0xFF
loByte = 0xFF

i2cbus.write_word_data(i2cradar,loByte,hiByte)
oldState = i2cbus.read_word_data(i2cradar,0x20)

while True:
 i2cbus.write_word_data(i2cradar,loByte,hiByte) #essential
 portState = i2cbus.read_word_data(i2cradar,0x20)
 if portState != oldState:
  bits ='{0:16b}'.format(portState)
  print bits.zfill(16), " ", time.localtime().tm_sec
  oldState = portState
  hiReflect = (portState >>8) & 0xFF
  loReflect = (portState & 0xFF)
  i2cbus.write_word_data(i2crelay,loReflect,hiReflect)
  time.sleep(0.1)
 else:
  time.sleep(0.01)

The SMBus class assumes that devices have registers, and that all accesses begin with a write of the register number. This is not true for the PCF.

To write to the PCF, use i2cbus.write_byte_data(addr, loByte, hiByte).
To read from the PCF, use i2cbus.read_word_data(addr, loByte).

(The write_byte_data call pretends that the first data byte is the register number. The read_word_data call writes a byte that gets ignored by the PCF because it acts only after two bytes have been written.)

Hi Clemens, I take your word for it, but your suggested code does not resolve the issue.

As long as the 'essential' line is not inside the while loop, I see the bits on the read port fall within a second, one after another, regardless off word- or byte read/write.

Generally speaking the order of falling is low bit to high bit (in a 16-bit word) but not exactly so and not every time the same.

I've swapped around boards, tried to lower the Vcc (which obviously did not work as Vcc min is 4.5V).

Then I added 5 MΩ  resistors between Vcc and the port pin (for 2 pins that connected to the radar module).

Lo and behold, the code (writing 0xFFFF once) then works for the two pins with resistors but other pins still drop.

Hence my suspicion is that due to capacitive loads (although the pcb tracks are only 5 cm long and end in a pin header) the pins cannot maintain the '1' state, and only briefly after writing do so (swing up, then fade low?). In other words: the internal pull up resistors seem not to be able to deliver enough power to keep the pins in an 'up' state. Measuring the voltage level on unconnected input pins confirm this. A pin written with '1' once reads 145 mV (as soon as the multimeter readout stabilizes and slowy dropping to zero) while a pin written '1' continuously reads  1.9V when Vcc is 5V). Attaching a volt meter (Voltcraft  VC170) is enough to pull a pin low, (unfortunately I do not own a oscilloscope or logic analyser).

This also seems to be in accordance with figure 13 of the datasheet (on page 15) where for the rise time of the voltage on the example pin P5 the iOHT is higher than IOH (which according to the table are -10mA vs -4mA).

Just touching with the bare hand the pins that were written once in '1' state, but have fallen since and thus read '0', is enough to read a '1' intermittently.

So all in all I do not yet know the exact cause of the problem but I can design my way around it by adding pull-up resistors to my PCB for every input pin. Unless, of course, given the observations above, you can give me a better solution.

Until now, I did not realise this. Thanks, this explains everything.

One more question to get a complete understanding of the difference between PCF8575 and PCF8575C: In the block diagram of the PFC8575 (without the C) the output pin is connected to a 100 mA current source through a p-channel mosfet. Would in using the PCF8575 in stead of the PCF8575C lie the solution of my problem? When writing high to the flipflop, this is cconverted to low by the inverter, and a low is fed to the gate of the p-channel mosfet, which opens and connects the 100mA current source to the output pin.

Or does the same activity limited to the ACK time here also hold?