Does I2c has a minimun clock freq ?

[fadeout]

Hello. So am I having trouble with I2C. I have the PC configured as Master with a Lib written by us.
The slave is a PIC 16F876.
Now I can have a million of problems (including PC-Side software problems), but first of all, after a day of insuccess and a lot of posts read, I have a doubt: is there a minimum clock freq for I2C ? The PC library, that uses parallel port to communicate I2C with the pic, every time has to generate a clock sleeps 1ms. This means that I'm going approx 1Kbit at second. Can this is a problem ? Or I can go as slow as I want ?

By the way at the moment I can't get the interrupt function start at all !

If can help here it is my simple simple slave code; at the moment I only would like to see a led turn on when a byte is received.... but it never happens !

:(

PS:
Compiler last version, downloaded yesterday!

[Felix Althaus]

Hi

According to the official I2C specs, there is no minimum clock frequency (p.32 in my version of the specs)

Felix

[fadeout]

That's right. I found it. Thank you.
I'm going to search where is the error...

Bye

[Ttelmah]

I have done code very like what you are illustrating, but with some major differences. I don't use I2C_POLL inside the interrupt. Instead, I directly read the status of the R/W bit in SSPSTAT, together with the BF bit, and SSPOV. If the slave is meant to be reading, I read the byte, otherwise I write my 'return' data.
Assuming that your master only sends, your code should work.
However the 'inbuilt' functions, have some significant shortcomings, when dealing with interrupt driven I2C, and I have found it much more successful, to 'cook my own', simply following the tables given in the MicroChip data sheet, about which status bits are set in which conditions, and code these directly.
As a seperate comment, you talk about using the parallel port to generate I2C. There could potentially be problems with this, unless you have added open-collector drivers, since though you can potentially drive SCL, and SDA, for data transfers from the PC to the PIC, when a transfer is wanted in the other direction, and the PIC, wants to perform a 'clock hold' state (pulling SCL low, till it is ready to respond with a byte), this would lead to the PIC, and the PC's output drivers fighting each other. Obviously if you have open-collector drivers, this comment doesn't apply, but then the comment, 'have you got the pull-up resistors', does. :-)
The question about timing, has two 'parts'. There is the 'spec', and then there are the individual chips. The spec, says that there is no lower limit, but _some_ chips do have problems at extremely slow speeds. I have in the past seen a problem with a particular ADC, which would reset itself if the entire transaction took more than perhaps 0.5 seconds. However your speed, in this context is still plenty fast enough, and the PIC has no such limit (unless deliberately programmed by using the watchdog, reset by the I2C).

Best Wishes

[fadeout]

Thank you Ttelmah; your suggestion are very interesting. I'm only a developer and my understand about elettronics is very poor, but this evening (Italy time) I'll meet who made the circuit and i'll talk about your considerations.

I'm think I'm going to try to do I2c by myself as I see many programmers here does.

Thank you a lot again.

Bye.

[Guest]

I2C does *not* have a minimum frequency, but SMBus does. A lot of people use the names "i2c" and "smbus" interchangeably, but SMBus has a minimum frequency of 10KHz (it is otherwise very very very similar).

Secondly, you *must* have open collector outputs and you *must* have pullup resistors on both the clock and data lines. Even if you are the slave of a write transaction, you have to be able to pull the data line low in order to ACK (acknowledge) each data byte that is written, and you will be unable to do that unless you have open collector drivers attached to your parallel port.

Good luck.

[fadeout]

Well: I'm quite new to PIC programming. Onestly I don't know what SMBus is... may I take a look to the PIC Datasheet ?

For the open collectors I'm goint to print this topic and bring it to my eletronic designer...

Thank you all again.

[fadeout]

I posted a new topic today because I can't get the stop bit, but now it seems to work quite well: there was a problem with a resistance on the circuit: incrementig that the PIC is now able to force down the lines.

Thank you.