Trouble with I2C - Part 1

[munromh]

Hey all,

I'm interfacing a Max5477 digital pot to a PIC16F627 with PicBasic Pro V2.47. It took me a bit to get it to work and the problem I see is that the I2CWRITE command's subsequent statements (DataPin, ClockPin, Control, Address, Value) don't work in the order that they're published. In order to get it to work I have to enter it like this:

I2cwrite PortA.6, PortA.2, Control_NVreg, value, Address

ie. I have to swap the Value and Address statement to get it to work.

With:
Control_NVreg = %00100001
Value = %10000000
Address = %01010010

http://www.soundunderwatersurvey.com/Downloads/Web_references/I2C Write.jpg

In all the other I2C posts I looked at everyone is using it in the published order.

Does anyone have a clue why mine is messed up?

Mark

[Darrel Taylor]

It's mostly a matter of differences in the naming of the paramaters.

MAX5477
Address - Command - Data

I2CWRITE
Control - Address - Value

The I2C Control, is what the MAX calls Address.
The I2C Address, is what the MAX calls Command.
What you are calling Control_NVreg, is what the MAX expects for the Command.

Here's what it should look like without changing the variable names.

I2CWRITE PortA.6, PortA.2, Address, Control_NVreg,[Value]
%01010010 %00100001 %10000000

Also, your address indicates that the A0 pin on the MAX is tied HIGH, with A1 and A2 tied LOW.

[munromh]

Hey Darryle, thanks for the response.

Well ..... One of two things, I either don't completely understand your answer or I don't think that's what I'm seeing. Let me walk through it.

>The I2C Control, is what the MAX calls Address

Looked at that in more detail, Okay, I agree.

If the I2C Value, is what Max calls Data then I agree by default that:

>The I2C Address, is what the MAX calls Command

So according to the PBP statement:

I2Cwrite DataPin, ClockPin, Control, Address, Value

The equivalent Max(imized) statement should be:

I2Cwrite DataPin, ClockPin, Address, Command, Data

Which is what you entered when you wrote:

>Here's what it should look like without changing the variable names.

And when I put it in that way ....... it ... ahhh .... works! ..... jeez.

Okay, thanks, I had to walk myself through that. Also, it solved another problem I was seeing but won’t get into here.

If I might add something else I'm seeing. If I write:

I2cwrite PortA.6, PortA.2, Address, Command_NVreg, Data_M
pauseus 100
I2cwrite PortA.6, PortA.2, Address, Command_NVreg, Data_M
pauseus 100
I2cwrite PortA.6, PortA.2, Address, Command_NVreg, Data_M

For simplicity write 80h to NVreg 21h on slave 29h three times.

What I see is that the first write statement executed fine:
http://www.soundunderwatersurvey.com/Downloads/Web_references/Write 80h to NVreg 21h on slave 29h three times-a.jpg

However the second write was incorrect:
http://www.soundunderwatersurvey.com/Downloads/Web_references/Write 80h to NVreg 21h on slave 29h three times-b.jpg

And the third was correct:
http://www.soundunderwatersurvey.com/Downloads/Web_references/Write 80h to NVreg 21h on slave 29h three times-c.jpg

This continues on and on and on ....

What apparently is happening is that the master isn't initiating a Stop sequence and the SCL line stays low .... apparently looking for the next Data Byte (?) ........ which it gets at the start of the next write, but we're trying to write the same thing again.

Anyway, then a proper Stop sequence is initiated and we're back to normal for the next Write.

Right around 1.2 mS where the Stop sequence should be SCL goes low before SDA goes high to initiate the Stop sequence.

Best regards,
Mark

[Darrel Taylor]

You're missing the brackets around the data.

The I2C command thinks it's still setting up the write, and doesn't send a STOP.
<br>

[munromh]

Ahhh, yes, that works. And you would've thought after reading all those posts about not forgetting the brackets..... I did mess with them a bit, however, I think after my nomenclature confusion between PBP and Maxim I'm not seeing the forest through the trees. Time to step back a bit.

Thanks,
Mark