i2c_slaveaddr() function behavior

[kerplatz]

I am having a problem understanding the behavior of the i2c_slaveaddr() function. I am using the most recent compiler version - 5.064. I need to set the i2c address of a board using hardware; the system will have multiple boards hence the need to have different addresses. So to do that I am using 2 16bit rotary switches to encode the address for that board. They work fine. For example, if I set the LSB switch to 0 and the MSB switch to 2, I get the value hex 20, or 32.

When I hard code the function it works fine and I can communicate with the board via i2c.

i2c_slaveaddr(stream1, 0x20);

But this is not what I want the code to do as I would need to compile new code with the address of that board for each board. Not a good option. So if I could do this--

i2c_slaveaddr(stream1, readHexSwitch());

or

unsigned char rhs = readHexSwitch();
i2c_slaveaddr(stream1, rhs);

where readHexSwitch() just returns the value of the switch positions in hex.

This is my question, why won't the latter work. I am so perplexed as this should not cause the code to work. It does however compile. A char and an int8 should be the same thing, right? I just compiled the code using int8 instead of char and it compiles, but does not work. Any help with this would be appreciated. Before you ask if I am using the correct address in i2c, if I go back to hard coding the address, then my i2c communications with that board return. I really need a way that the hardware and software place nicely together, so I can communicate with several boards via i2c on the same wire. Thanks.

[Ttelmah]

First, a function won't 'return a value in hex'. All internal values are binary. Hex is just a way for us to represent these. So your function will hopefully just return a number.
That having been said, problem is that the slave address is a hardware function, has to be set before the port is initialised, and there are some addresses that can't be used.
So ideally what you do, is use the 'NOiNIT' option, set the address, and then use I2C_INIT with the address selected.
To change it after initialising, close the port, and re-initalise. So:

[kerplatz]

This did not work.

I set #use i2c((SLAVE, I2C3, address=32, FAST=400000, FORCE_HW, stream=SYSTEM_BUS). Then in an initialization function I used this code--

i2c_init(SYSTEM_BUS, 0);
i2c_slaveaddr(SYSTEM_BUS, 34);
i2c_init(SYSTEM_BUS, 1);

and my address did not change to 34 as I can still communicate to the board via i2c. Since I changed my board address, communications via i2c should have stopped. Please advise.

[PCM programmer]

You didn't give us your PIC but I believe it's a 24F series.

I don't have the PCD compiler, so I did a test with an 18F46K22.
The i2c_slaveaddr() function compiles to one line of code:

[kerplatz]

The chip is 24FJ256GA106.h. I am using the other 2 i2c devices to do other things, they are working perfectly, hence why I said nothing about them. PS - They never leave the board. (I am doing R & D where we design and make our own boards.) So now that I have given more meaningless info to my problem, let's get back to the problem.

As I have said the code does compile, which is not the problem. It is execution. Please go back and reread what I have told you. If you need more info, ask a question and I will give you an answer. Here is a synopsis of the problem.

I can set the address in #USE I2C() and it works fine. If I use i2c_slaveaddr() it works only sometimes. I gave some examples. What I want to do is be able to set the address using hex switches so I only need to have one version of the code. Surely this is not the first time someone has done this. This is not, as far as I can tell, an initialization problem as I can make it work when I don't use i2c_slaveaddr(), I just can't change the address how and when I want to. I apologize for being somewhat snarky today, but I have been fiddling with this for a while now and I want to work towards a solution. My frustration level is high.

[kerplatz]

Here is what the .lst file gives for those three lines of code. I will now go and figure out what it is doing.

.................... // Read the hex switches.
.................... i2c_init(SYSTEM_BUS, 0);
006EE: BCLR.B 277.7
.................... i2c_slaveaddr(SYSTEM_BUS, 34);
006F0: MOV #11,W4
006F2: MOV W4,27A
.................... i2c_init(SYSTEM_BUS, 1);
006F4: BCLR.B 2E4.7
006F6: BSET.B 277.7
006F8: BSET.B 277.5
006FA: BSET.B 276.6
006FC: BCLR.B 277.3
006FE: BSET.B 276.7
00700: BCLR.B 277.0
00702: BCLR.B 277.1
00704: BCLR.B 277.2
00706: MOV #10,W4
00708: MOV W4,27A

Yes I know the address is not 32 as I am trying to change it to a different one than what I started with. Here is the #use i2c() line.

#use i2c(SLAVE, I2C3, address=32, FAST=400000, FORCE_HW, stream=SYSTEM_BUS)

[Ttelmah]

On this port as shown, the compiler is behaving incorrectly, and always setting the address to the value from the #use...

So use:

[kerplatz]

OK, so I removed the BAUD from my #USE_I2C setting. I get that the slave is dependent upon the master clock so this has no effect. But this is not my problem. The value contained in the I2CXADD is the address I2C will respond to when sent a message via I2C. I know all about how it works as I have written code for I2C communications many times. I am not a newbie. Can still make mistakes, but this problem was not my mistake. Read on.

As promised, I went back and studied my code using the debugger where I discovered that I could see all the registers for all the peripherals on that chip. I put my code back to where I was initializing the I2C3 like this--

[Ttelmah]

That's the point of this line:
"Remember PIC24 uses 7bit address mode.".

There are two different standards for I2C addresses. Technically the 'address' is the top 7bits of the byte sent on the bus. The bottom bit is the Read/Write flag. The byte being sent then, is the actual 'address' *2 plus the direction flag. On a lot of chips you then talk about the 'address' as this 8bit value.
On the PIC16/18, the register holds the 8bit address. On the PI24, the register instead wants the 7bit address....