Another I2CWRITE problem

I believe I must be missing something here. My harware is 100% as it is tested with some code from a diffrent compiler and it works just fine.

I load the code from PBP and get garbage.

What I see is what looks like a correct I2C write cycle (even ack is correct), except the clock line does not go high at the end before the data line (illegal stop generated). The clock line then stays low until the next run thru the loop, where the correct data states are generated, but no acks.

Yes, there are pull-ups there. The hardware works with other code.

What could be missing that the PBP compiler needs?


DEFINE OSC 8 ' 8 MHZ CLOCK

asm
__config _CONFIG1, 2f50h ; no clock out
__config _CONFIG2, 3ffch
endasm

d2a_addr CON %00100000
I2C_addr var byte
I2C_data VAR Word

init:
OSCCON = %01110000 ' use internal 20MHz clock
ANSEL = %00000001 ' AN0 only as analog 16F88


loop:
I2C_addr = d2a_addr
I2C_data = $CC80

I2CWRITE PORTA.7, PORTA.6, I2C_addr, I2C_data

pause 5

Goto loop

Hi ErnieM,

On the 16F88, PortB.1 and PortB.4 are used for I2C . (Datasheet!) B1 is the data line and B.4 is the clock line. Try switching to these pins and you should work. I'm currently working on 2 projects using an I2C RTC and a 16F87 which is the same pinout as the 16F88.

BobK

are you sure you PIC is alive? did you do some blink test before?

Just because i'm lazy, are you sure of your OSCCON and ANSEL setting?

Are you sure that your Config Fuse setting is really what you want?

NOW just read the I2CWRITE and discover that you forget 2 things, one in the way to write the I2CWRITE statement and one other about BYTE and WORD to be send...

@BobK
uneless you use the Internal MSSP module, you can use almost any i/o.

Ah ha! The 'data' portion of the transfer needs brackets. Otherwise the compiler accepts them as good but doesn't issue the I2C stop condition.

Another "feature" of PBP, a silent compile error.


Bob:

Quote:

---

On the 16F88, PortB.1 and PortB.4 are used for I2C . (Datasheet!) B1 is the data line and B.4 is the clock line.

---

That would be true if PBP used the internal hardware for I2C. It doesn't, it just bit bangs the ports (well, actually the tris registers so it can do open collector type outputs). If you skim down a disasembly listing or memory listing (something MPLAB will get for you if you load both the hex and cod files) you'll see it doing this.

I did not used the hardware I2C for several reasons, mainly I don't want hardware I2C support to be a PIC choice requirement.

Hi ErnieM,

I honestly did not know that there was both a hardware and a software I2C setups on PICs similar to serial. But, that's why were here isn't it? To learn! Here I am searching for PICs that have I2C pins when I could have used maybe something different. Thanks for the additional knowledge.

BobK

HPWM, HSERIN, HSEROUT will use the PIC dedicated pin as it use the internal Hardware module. SERIN/SEROUT/I2CREAD/I2CWRITE/SHIFTIN/SHIFTOUT are a software solution and may be used on almost any i/o of your PIC.

Maybe one day we will have HI2CREAD/Hi2CWRITE/HSHIFTIN/HSHIFTOUT, in the meantime, we used those we spend hours/days/months on.

Thanks Mr E for the education. That's what I like about this place! Always something to learn.

BobK