i2c and #use fast_io(x) ?

Guest · Posted: Thu Jun 29, 2006 2:07 am

Can I use: #use fast_io(a) without change tris direction when I have I2c on port A ?

#use I2C(master, sda=PIN_A1, scl=PIN_A0)

#use fast_io(a)

SET_TRIS_A(0b00011000);

Thanks de Picfan

epideath · Joined: 07 Jun 2006 Posts: 47

As long as the PIC that you are using has hardware I2C then the ports will be configured when ever you enable I2C

Ttelmah · Guest

Software IC, is actually 'done', by the compiler changing the TRIS register. Basically, it sets the two pins to 'low' in the output latch, and then changes the setting in TRIS, to '1' for an input, when the line is to be driven high (by the external resistors), and to '0' when it wants to drive this low. It does this whatever IO mode is selected. If you leave the pins set as inputs (so they are effectively floating), the compiler will generate the I2C master, changing the settings as needed.
The only problem appears, if you enter the I2C routine, with the lines already 'driven' (set as outputs).

Best Wishes

Guest · Posted: Fri Jun 30, 2006 2:27 am

Tnx for reply....but this is hard to understood for me.

My project is a ATV receiver for 1.2Ghz and use a 16f628 for drive a Tuner Philips UV916.

I use a function (found on the web) for see if the pll is locked or not but in my loop routine, returncode alternate: ok, 0b11111111, ok, 0b11111111, ecc.

Any change in other pin of PLL, so 0b11111111 is false reading...

Prg is:

Ttelmah · Guest

Number of comments.
As I said before, the I2C code, takes over the required bits to send the data, but the pins should be set to inputs before calling the routine. Your TRIS statement sets the bits as outputs, but is also being shown in the 'declaration' area (outside the code), so will not work....
Have you got the I2C pull up resistors?.
You should 'NACK' the fetch of the last byte (returnCode = i2c_read(0);).

Best Wishes