![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
fadeout
Joined: 28 Jan 2004 Posts: 15
|
Does I2c has a minimun clock freq ? |
Posted: Mon Feb 09, 2004 1:48 pm |
|
|
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!
Code: |
#include <16F876.h>
#device *=16
#device ICD=TRUE
#device adc=8
#use delay(clock=4000000)
#fuses NOWDT,RC, NOPUT, NOPROTECT, BROWNOUT, LVP, NOCPD, NOWRT, NODEBUG
#use i2c(Slave,sda=PIN_C4,scl=PIN_C3,address=0xa0,FORCE_HW)
#byte SSPADD = 0x93
#int_SSP
SSP_isr()
{
int8 InByte;
output_high(PIN_B2);
if (i2c_poll()==FALSE) return;
else
{
InByte = i2c_read();
output_high(PIN_B3);
}
}
void main()
{
int i=0;
int8 InByte;
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_counters(RTCC_INTERNAL,RTCC_DIV_1);
setup_timer_1(T1_EXTERNAL|T1_DIV_BY_1);
setup_timer_2(T2_DISABLED,0,1);
enable_interrupts(INT_SSP);
enable_interrupts(global);
output_low(PIN_B3);
output_low(PIN_B2);
while (TRUE)
{
output_high(PIN_B5);
delay_ms(500);
output_low(PIN_B5);
delay_ms(500);
}
}
|
|
|
![](templates/subSilver/images/spacer.gif) |
Felix Althaus
Joined: 09 Sep 2003 Posts: 67 Location: Winterthur, Switzerland
|
|
Posted: Mon Feb 09, 2004 2:08 pm |
|
|
Hi
According to the official I2C specs, there is no minimum clock frequency (p.32 in my version of the specs)
Felix |
|
![](templates/subSilver/images/spacer.gif) |
fadeout
Joined: 28 Jan 2004 Posts: 15
|
|
Posted: Tue Feb 10, 2004 2:32 am |
|
|
That's right. I found it. Thank you.
I'm going to search where is the error...
Bye |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Tue Feb 10, 2004 3:35 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
fadeout
Joined: 28 Jan 2004 Posts: 15
|
|
Posted: Tue Feb 10, 2004 3:45 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Guest Guest
|
|
Posted: Thu Feb 12, 2004 12:17 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
fadeout
Joined: 28 Jan 2004 Posts: 15
|
|
Posted: Fri Feb 13, 2004 4:34 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
fadeout
Joined: 28 Jan 2004 Posts: 15
|
Quite Done |
Posted: Sat Feb 14, 2004 11:37 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|