I2C

[YAN-1]

Hello. I have an inquiry to make regarding the I2C port of the 16f877. I have it working alright but there is something strange happening. It says in the datasheets that the SDA and SCL pins must be set as inputs. I did that and it works fine except for one slave. If I set its I2C pins as inputs, things get stuck. If I comment out the 'TRISC = 0x00011000;' line, things work fine again! The SDA and SCL pins of the other slaves are set as inputs and things are fine with them. Can anyone please provide an explanation for this? Thanks a lot.

Nichola V. Abdo

 

[Nigel Goodwin]

Hello. I have an inquiry to make regarding the I2C port of the 16f877. I have it working alright but there is something strange happening. It says in the datasheets that the SDA and SCL pins must be set as inputs. I did that and it works fine except for one slave. If I set its I2C pins as inputs, things get stuck. If I comment out the 'TRISC = 0x00011000;' line, things work fine again! The SDA and SCL pins of the other slaves are set as inputs and things are fine with them. Can anyone please provide an explanation for this? Thanks a lot.

I suggest you check on the PICList, there are a number of problems with the I2C hardware implementation, and they were discussed long ago on the PICList.

 

[Oznog]

If I comment out the 'TRISC = 0x00011000;' line, things work fine again! The SDA and SCL pins of the other slaves are set as inputs and things are fine with them. Can anyone please provide an explanation for this? Thanks a lot.

Nichola V. Abdo

Probably because "0x00011000" means hex 00011000! It takes the least significant hex zero there, considers that to be 8 binary bits of zeroes, and throws away the other excess 7 hex digits. That sets SDA/SCK as outputs.

You want binary:
"TRISC = 0b00011000;"

Do be sure to read the errata for your particular part and revision's I2C module. uC put out some buggy versions. Additionally be aware their module and the protocol itself is somewhat vague. If I recall the master pretty much needs to have the code keep track of its state but the slave needs to look at the interrupt flags to determine the state. It's possible the master or slave can encounter unexpected flags. In that case you need to decide what the code should do to resolve it.

 

[evandude]

Probably because "0x00011000" means hex 00011000! It takes the least significant hex zero there, considers that to be 8 binary bits of zeroes, and throws away the other excess 7 hex digits. That sets SDA/SCK as outputs.

Well, 1 hex digit only represents 4 bits, not 8, so it would be taking the lowest two digits... but otherwise you are correct, it sounds like that must be his problem, since the default power-on state for most I/O pins is input, so the fact that it works when he comments that line out is a dead giveaway.

One good thing to have is a proper logic probe, which can tell you if a pin is high or low (set as an output), or high-impedance (set as an input). A quick probing of your two "input" pins would have revealed that they weren't actually inputs. I use mine with PIC projects very regularly, because of how easy it is to mis-type something, or forget to disable certain internal functions like comparators or parallel slave ports, so it's always helpful to know for sure whether all the pins are properly set as inputs/outputs as you expect :lol:

 

[YAN-1]

OH MY GOD :x

I CAN'T BELIEVE I MADE THAT MISTAKE! I type '0x' automatically these days The other slaves were configured correctly.

As for the vagueness of the I2C protocol, I managed that a few months ago. I studied it well and wrote my subroutines for the master and my interrupt service routines for the slaves and i guess it's pretty good. I just have to make the stupid mistake of '0x'. :evil:

Anyways.... Thanks a lot for pointing it out. I was beginning to blame Microchip I can't wait to go back to uni tomorrow morning and correct it and see it work beautifully.