i2c_write return value

[pmuldoon]

chip: 16F1779
compiler: V5.074
Can anyone clarify what the return value is for i2c_write()?

The compiler manual says:

[Ttelmah]

The device acknowledges receipt by holding the data line low when the master releases it. This is part of the key of I2C, where because the bus is 'open collector', there can (with the right timings) be communications both ways.
The write returns this bit.
So if the signal goes high, the device has not acknowledged. If is is zero the device is acknowledging.

Now the bus is not correctly valid at either voltage you mention.

Is your PIC running at 5v?. A lot of the I2C displays are 3.3v devices. Though they have voltage regulators to run at 5v, the output signals are not compatible with a 5v PIC.....
I'd suspect this is your problem. You can build a level translator with a FET.

[pmuldoon]

Oh, well that's embarrassing!

You're right, the ACK is active-low. I saw the half-way-up signal and just assumed it was trying to go up instead of down.

It is a 3V3 PIC and display, but the pullup is 1.5K. The datasheet for the display recommends 10K which I thought was rather weak.

The other I2C device on the bus is a TCS3490 color sensor and it's datasheet recommends 1.5K pullups. I guess that's where I got that value from.

Thanks for the quick reply. Now if you can just bury this thread so no one can see what a dumb assumption I made....

[Ttelmah]

10K is very low. Is the device standard speed only?. Basically any fast device is meant to be able to pull down 3mA. For a low capacitance bus, 10K is legal, but only for 100K max operation.

Having a 0v as the 'ACK' (and 5v as NACK), is a very confusing feature of I2C....

[pmuldoon]

300K at 3V3 is what the datasheet says.
NewHaven Display NHD-C0220BiZ-FS(RGB)-FBW-3VM.

Thanks for the supportive comment. I have trouble with up and down sometimes too, LOL.

[Ttelmah]

Hmm. I don't see where they specify the I2 current capabilities. However for 300KHz at 400pF (which they claim), it'd have to be able to support a 1KR pull-up to give the required switching times (300nSec). Are you sure your supply is not dropping when the I2C drives?.
It doesn't matter so long as you keep the data rate low, or the bus capacitance is low, but something doesn't quite 'add up' in the figures....

300K is a sort of 'in between' rate, with I2C only actually specifying fast mode at 400KHz, or standard mode at 100KHz.
Get yourself a copy of SLVA689, which is the Texas application note about I2C pull up calculation.

It should be pulling down better than this. Triple check the connections. Something like a resistive connection on the ground to the unit would give the poor pull-down.

[pmuldoon]

Thanks, I'll take a look at the gnd.

Something seems fishy about their recommendation of 10K pullups. I changed the resistors to 10K and it pulls low fine, now. Since we're not planning on using the color sensor that may be the end the issue.

I also started actually checking for the ACK. I always just write blindly to serial (UART) displays and never had a problem, til now. Since I have an ACK I might as well use it.

I also slowed the clock a bit. I noticed that the clock period is very stable until the ACK pulse. For some reason that one is shorter than the rest.

So, the display was struggling to pull down the ACK pulse, and seeing a fast clock during ACK. Maybe that was enough to cause an occasional problem.
I had it running all night and will continue to see if it messes up again and see what happens. I will also check the ground as you suggested.

I've been working on my first ARM project where absolutely NOTHING works on the first try and useful info is scattered across multiple huge data sheets (ARM-ST-HAL-Cube). It's so nice to play with a simple PIC problem again!