I2C, FORCE_HW, slow, fast trivia - trying to sort out things

[AsmallGuy]

All right, compiler v4.093, i'm starting to experience with I2C, so i'm not a pro, but i know little (from the forums) about:

_ pull-ups check
_ i know about the i2c_read(0) NAK for the last read from master vs slaves
_ Master:

#use i2c(Master,fast=100000,I2C1)
#define SLAVE_W 0x14
#define SLAVE_R 0x15

_ Slave:
#use i2c(Slave,I2C1,address=0x14,FORCE_HW)

I'm not asking "my system isn't working", actually i would like to know why and how it is working :D

Actually my questions try to cover a broad range of issues on the I2C topic; yes, i've read quite a few pages from the forums and that's why i wanted to sum up everything in here ;) - I'm using a PIC16F690 to experience, one as master, the slave with a adc_read to feed data; the master is asking the slave for the value.

1. Why the master is not working with the FORCE_HW directive? i read "0" and the code is running (i have a toggle led in the main loop)

2. Why I2C_speed(xx) and I2C_poll() are not working without force_hw?

3. How can i tell if the master PIC is using a software implementation or HW of the I2C?

4. What's the differences between "fast=100000" and "slow" parameter? any adavantages?

My small setup is working, only i'm just wondering of so many small things not explicitely written, changed, hacks and mods to make it go

Tnx!

[Ttelmah]

The I2C_SPEED question, is the same as for the 'set_uart_speed' function.
The software I2C, in common with the async serial, is done by using custom timing loops to get all the timings. To change the speed, you have to change the actual code in all these loops (not just changing a counter, but actually altering the number of nop instructions etc.). Hence you can't change the speed for the software code 'on the fly'. You can change the speed, by setting up two streams with the required speeds, and selecting the one you want, but this then generates two sets of software I2C driver code, with all the loops altered.....

I2C_POLL, tells you that the hardware has received a byte. No hardware to do this with software I2C...
Remember that with the hardware, reception goes on independant of the running code. With software, there is no such ability, and nothing for I2C_POLL to tell you.

At heart, no difference between using 'fast=xxx', and using 'slow'. Slow is the older syntax, and until fairly recently, was the only 'speed' option available.

Without seeing your code, difficult to know 'why' it doesn't work with FORCE_HW. However, 'what compiler version'. There are issues on some compilers not initilalising sme peripherals correctly, and this could be your I2C problem. Also, when using the hardware peripheral, the inputs are Schmitt trigger inputs, requiring better pull-ups, than wil work for the software.

Best Wishes

[PCM programmer]

[Guest]

Thanks all for the initial suggestions.

FORCE_HW: I'm using the PIC16F690, the master has

[mewanchyna]

For the record, I have similar issues with the the software and hardware I2C. Code works in software but not when I "force_hw". I'm using CCS 4.030. I will post any results that I find.

[ckielstra]