i2c PCF8474N problem

Hi,I have created a simple LED blinker using i2C (PCF8574N from Texas Instrument) and raspberry rev1 board. The LED is very DIM. I am not sure what is the problem, its almost like not on. (I have to reduce the lights in the room so see the LED glow). What could be the problem?

8574.png (14.63 KiB) Viewed 909 times

i2cdetect -f 0 tells me that the device is at address 0x20. And below is the simple i2c code.

Update:I think i figured it out. I have to connect the LED this way.+5V to LED to Reresistor to P0 of P8574 pinAccording to the specifications on the datasheet, the 8574 can source only about 0.1ma, but can accept around 20 milliamps.Please correct me if i am wrong.

kashwath wrote:Hi,I have created a simple LED blinker using i2C (PCF8574N from Texas Instrument) and raspberry rev1 board. The LED is very DIM. I am not sure what is the problem, its almost like not on. (I have to reduce the lights in the room so see the LED glow). What could be the problem?

8574.png

i2cdetect -f 0 tells me that the device is at address 0x20. And below is the simple i2c code.

Update:I think i figured it out. I have to connect the LED this way.+5V to LED to Reresistor to P0 of P8574 pinAccording to the specifications on the datasheet, the 8574 can source only about 0.1ma, but can accept around 20 milliamps.Please correct me if i am wrong.

This chip has what's effectively an open-collector output driver, so going from +ve through led/resistor to pin is the way to do it. Not all chips are like this, some (like the Pi) have equal source and sink capability - you do need to read the destructions!

The PCF8574N is a rather curious chip though - it uses the rather interesting term: "quasi-bidirectional IO port"... I wrote a little driver for it with wiringPi while back - there is no mode register, to put a pin into read-mode, you need to write 1 to the pin, then there is a 0.1mA current source from +ve to the pin - so that's like a pull-up resistor - you connect the pin to +ve and it's fine, or connect the pin to 0v and it pulls it low for the read gate to recognise it.

However, connect the pin to +ve and write 0 to the pin and you let the magic smoke escape...

It doesn't internally appear to pull the I2C lines to +ve, so running it at 5v off the 3.3v Pi is probably fne too.

gordon@drogon.net wrote:It doesn't internally appear to pull the I2C lines to +ve, so running it at 5v off the 3.3v Pi is probably fne too.

No true I2C device should pull up the I2C lines as the I2C bus is an open collector/drain wire-NOR bus with normally one common pullup resistor.

This is why a lot of poorly constructed I2C controllers that tie two standard port pins for pseudo bi-directional SDA line often have problems. An example being I2C mode on FTDI chips using the MPSSE engine (FT2232 etc).

Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreadingor http://www.pcserviceselectronics.co.uk/pi/

gordon@drogon.net wrote:It doesn't internally appear to pull the I2C lines to +ve, so running it at 5v off the 3.3v Pi is probably fne too.

No true I2C device should pull up the I2C lines as the I2C bus is an open collector/drain wire-NOR bus with normally one common pullup resistor.

This is why a lot of poorly constructed I2C controllers that tie two standard port pins for pseudo bi-directional SDA line often have problems. An example being I2C mode on FTDI chips using the MPSSE engine (FT2232 etc).

I'm under the impression that some Fast (1MHz) and Ultra Fast (> 1Mhz) devices can actively pull the bus high (constant current driver) to decrease the time take to get the bus back to +ve...

gordon@drogon.net wrote:It doesn't internally appear to pull the I2C lines to +ve, so running it at 5v off the 3.3v Pi is probably fne too.

No true I2C device should pull up the I2C lines as the I2C bus is an open collector/drain wire-NOR bus with normally one common pullup resistor.

This is why a lot of poorly constructed I2C controllers that tie two standard port pins for pseudo bi-directional SDA line often have problems. An example being I2C mode on FTDI chips using the MPSSE engine (FT2232 etc).

I'm under the impression that some Fast (1MHz) and Ultra Fast (> 1Mhz) devices can actively pull the bus high (constant current driver) to decrease the time take to get the bus back to +ve...

The Spec does specify anything like this I2C devices from folks like Ramtron are available in upto 1MHz versions, the High Speed mode 3.4Mb/s, has buffer differences that are the same as Fast Speed (400kHz) of input buffers must be Schmitt trigger with spike suppression. Even Figure 20 (page 21) of the 2000 version of the spec only has open drain configuration, with additional pull DOWN for clock stretching (only after acknowledge bit). It is more likely that at 3.4Mb/s you would have small series resistors on the lines for spike suppresion. Slope control is specified but that should be how the open drain stage is driven.

The spec does not call for any form of pull up active or passive only the standard pull ups.

Some manufacturers may do this for many reasons including to overcome design problems with input stage loading of bi-directional ports, how the ESD protection works, unable to perform slope control properly and any other reason from this is our standard ouput buffer cell to we have decided to redesign the spec to our version.

Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreadingor http://www.pcserviceselectronics.co.uk/pi/