Philips PCF 8591

[Charles Linquis]

Has anyone successfully read a Philips 8591 using PBP? I can "talk" to virtually any other device I have come across, but this one has me stumped.

Can someone tell me what I'm doing wrong? And yes, I have pull-ups on the SCL and SDA lines!

Code is below.
---------------------------------------------------------------------

PCF8591 CON %10010000

SetupI2C:

DevAddr = 0
DevAddr = DevAddr << 1
DevAddr = PCF8591 | DevAddr
I2CWRITE PORTC.4,PORTC.5,DevAddr,$44,[0] ; Use internal clk, auto-increment mode
RETURN

ReadI2C:

DevAddr = 0
DevAddr = DevAddr << 1
DevAddr = PCF8591 | DevAddr
I2CREAD PORTC.4,PORTC.5,DevAddr,[PSByte1,PSByte2,PSByte3,PSByte4] ; Read all 4 channels

RETURN

[BobK]

Hi Charles,

I was really waiting for one of the gurus to answer this as I am no expert in I2C but I think the problem is in the DevAddr setup. Did you try breaking this down into all of the separate elements? "DevAddr = PCF8591 | DevAddr" is a logical ORing of "PCF8591" and DevAddr when you should be addressing the address byte and the control byte separately. I have only used I2C for the DS1337 RTC and have tried it once with the 8574A chip. No problems. I do understand after looking at the datasheet that this is a little out of my league but the concept is basically the same.

Also in the receive section, don't the PSbyte's have to start with PSbyte0 first? Your variables aren't listed so I don't know how you have them set up.

HTH,

BobK

[skimask]

Has anyone successfully read a Philips 8591 using PBP? I can "talk" to virtually any other device I have come across, but this one has me stumped. Can someone tell me what I'm doing wrong? And yes, I have pull-ups on the SCL and SDA lines!

Code is below.
---------------------------------------------------------------------

PCF8591 CON %10010000

SetupI2C:

DevAddr = 0 : DevAddr = DevAddr << 1 : DevAddr = PCF8591 | DevAddr
I2CWRITE PORTC.4,PORTC.5,DevAddr,$44,[0] ; Use internal clk, auto-increment mode
RETURN

ReadI2C:

DevAddr = 0 : DevAddr = DevAddr << 1 : DevAddr = PCF8591 | DevAddr
I2CREAD PORTC.4,PORTC.5,DevAddr,[PSByte1,PSByte2,PSByte3,PSByte4] ; Read all 4 channels

RETURN

I just read the datasheet. Check page 19, SCL freq. The PCF8591 is a 100khz device, not 400khz (or even 1mhz for that matter).
You probably have to use:
DEFINE I2C_SLOW 1
in your code to slow it down a bit.

[Charles Linquis]

OK, a bit more explanation.

I DO have the DEFINE I2C_SLOW 1 in my header,

Also,
The logical OR is to set the actual device address.
The "identifier" address of the PCF 8591 is %1001xxxy,
where "xxx" = the sub-address (as set by the 3 hardware
addressing pins), and "y" is the Read/Write bit. I have to shift
the sub-address (or hardware address) left with the << 1
to align it properly.

So, with my ORing statement, I'm actually sending

%10010000

(the chip has all 3 hardware address pins grounded)

Then I'm sending $44, which is supposed to be the control byte,
Then a data byte of "0", to tell it to start at channel "0"

The datasheet says $44 is the command to put it in the "auto-
increment" mode with "internal oscillator". After that, all you are supposed to have to do is read the chip.

A READ is supposed to give me all 4 channels at once.

I2CREAD PORTC.4,PORTC.5,DevAddr,[PSByte1,PSByte2,PSByte3,PSByte4]

The chip doesn't care what I call the bytes.




If any of this isn't correct, please tell me. Maybe that will help me
solve my problem.

[BobK]

Hi Charles,

Isn't the "Write" DevAddr suppose to be different than the "Read" address with the LSB being a "0" for write operation and a "1" for a read operation?

Thank you for the explanation of the ORing. I'm learning more here!

BobK

[Charles Linquis]

PBP automatically changes bit0 in the string. It handles the differences between WRITE and READ.

[skimask]

OK, a bit more explanation.

I DO have the DEFINE I2C_SLOW 1 in my header,


Ah...and I thought for sure I had it.
But another idea hit me looking thru the code...
You've got the R/W set to 0, should be a 1 for a read and 0 for a write.
Maybe, maybe not. Seems like that's the way it is for the other eeprom's I use.

I'm a bit late on the refresh button I'm thinking! You guys already got it...

[Charles Linquis]

Check the PBP mqnual. PBP *AUTOMATICALLY* sets the LSbit to the
correct value. That is, the I2CREAD instruction FORCES the bit to "1"
and I2CWRITE FORCES it to "0". Try it in your code, and you will find
that it works.

[skimask]

Check the PBP mqnual. PBP *AUTOMATICALLY* sets the LSbit to the
correct value. That is, the I2CREAD instruction FORCES the bit to "1"
and I2CWRITE FORCES it to "0". Try it in your code, and you will find
that it works.

I know. I was jumping back and forth while typing in my last post, checking the datasheet for the PCF, the manual, I2C spec's, etc. I should've hit refresh before submit!

[sougata]

Hi,

Have you tried the DEFINE I2C_HOLD 1 in your prog ? Any difference using or not using it ?

[Charles Linquis]

Hi,

Have you tried the DEFINE I2C_HOLD 1 in your prog ? Any difference using or not using it ?



Yes, I tried that. No difference.

[sougata]

Hi,

There has been no update. Please do let us know if you succeed and how.

[Acetronics2]

Hi, Charles

Found a demo here ... :

Listing 2
' Nuts & Volts "Stamp Applications" -- November, 2001

... may be it will help

Alain

[circuitpro]

Hi Charles (long time - no hear),

Did you ever find the answer to this problem? I'm looking at using the chip, but not if there's unforseen gotchas.

Thanks!
Len