i2c PCF8474N problem


10 posts
by kashwath » Tue May 21, 2013 5:54 pm
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
8574.png (14.63 KiB) Viewed 614 times


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

while : ; do i2cset -f -y 0 0x20 1 0x01 && sleep 0.3 && i2cset -f -y 0 0x20 1 0x00 && sleep 0.3; done


Update:
I think i figured it out. I have to connect the LED this way.
+5V to LED to Reresistor to P0 of P8574 pin
According 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.
Posts: 6
Joined: Thu May 09, 2013 9:10 pm
by techpaul » Wed May 22, 2013 8:51 pm
Running LED from 5V through resistor to port pin is best way for most drivers as they can sink more current than they can source. This is the normal way to do it.

This is best way to get things working.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by gordon@drogon.net » Wed May 22, 2013 9:14 pm
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.

while : ; do i2cset -f -y 0 0x20 1 0x01 && sleep 0.3 && i2cset -f -y 0 0x20 1 0x00 && sleep 0.3; done


Update:
I think i figured it out. I have to connect the LED this way.
+5V to LED to Reresistor to P0 of P8574 pin
According 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.

If you have the latest wiringPi, could you try:

gpio -x pcf8574:100:0x20 write 100 1
gpio -x pcf8574:100:0x20 write 100 0

To toggle the LED?


-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1494
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by techpaul » Wed May 22, 2013 9:30 pm
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/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by kashwath » Wed May 22, 2013 11:52 pm
Thanks a lot guys. The sink method worked. I also downloaded the latest WiringPi works like a charm.

Anyway, i had purchased this chip to drive a seven segment display, but i just realized that i have a common cathode display. Dang!! such a shame!! :oops:
Posts: 6
Joined: Thu May 09, 2013 9:10 pm
by techpaul » Wed May 22, 2013 11:57 pm
You could put a ULN2803 between the two maybe cheaper than changing or buying different 7 seg.

Depends how much wiring you want to do and board space etc........
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by kashwath » Thu May 23, 2013 12:43 am
okay. I will try that. However i am tending more towards buying a new seven segment, my board is running out of space.
Posts: 6
Joined: Thu May 09, 2013 9:10 pm
by techpaul » Thu May 23, 2013 1:39 am
Just realised what I was thinking is possible with just PCF8574, NOT very power efficient but what you do is

1/ Wire seven seg cathode to gnd and segments to pcf8574 port pins

2/ Work out resistor that gives reasonable brightness for LED when on

3/ Check current resistor will give when 5V across it so less than 20 mA

4/ wire separate resistors for segments to 5V

When PCF8574 output is high LED is on

When output is low LED is off as current diverted through port pin at almost gnd, this will draw more current through resistor.

So if 330R gives good enough bright brightness when LED on, (approx 9mA), this will mean current through resistor when LED is OFF is approx 15 mA.

Not ideal method but a way to get you going.
Just another techie on the net - For GPIO boards see http:///www.facebook.com/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK
by gordon@drogon.net » Thu May 23, 2013 6:39 am
techpaul wrote:
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
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1494
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by techpaul » Thu May 23, 2013 10:55 am
gordon@drogon.net wrote:
techpaul wrote:
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/pcservicesreading
or http://www.pcserviceselectronics.co.uk/pi/
Posts: 1509
Joined: Sat Jul 14, 2012 6:40 pm
Location: Reading, UK