 |
 |
| View previous topic :: View next topic |
| Author |
Message |
davefromnj
Joined: 03 May 2007
Posts: 42
|
| Quick I2C & PLL question |
 Posted: Fri May 04, 2007 1:33 pm |
 |
|
Hello All,
I have a project with 3 pics connected on an I2C bus. Everything runs great when all the pics are running at 4MHz. When the Master unit uses the 4x PLL multiplier and runs at 16MHz, the slaves seem to loose communication.
Compiler is 4.029. Is there an issue with 4x PLL multiplied MasterPic & SlavePics running at different frequencies with I2C?
Thanks |
|
 |
Ttelmah
Guest
|
|
| Posted: Fri May 04, 2007 2:49 pm |
|
|
There shouldn't be.
However you will need to remember, that (assuming the slaves are interrupt driven), in terms of the 'master' device, they will take four times as long to reach the interrupt handler etc..
My guess would be that the master is doing something faster than the slaves can handle when at the higher rate.
Best Wishes |
|
|
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Fri May 04, 2007 3:07 pm |
|
|
I had a project where I had two PIC's talking via I2C. I had things working nicely until I had to change the Slave's crystal from ~19MHZ to ~12MHZ. Things went belly up. I put a scope on the bus and noticed that I needed to put some delays, in the Master code, to allow the Slave to have time to do it's thing. Like Ttelmah, I would imagine this is what your problem is.
Try putting some nice size delays between each I2C command and get it working. Then, gradually, reduce each delay until you get it fine tuned.
Ronald |
|
|
libor
Joined: 14 Dec 2004
Posts: 288
Location: Hungary
|
|
| Posted: Sun May 06, 2007 3:03 am |
|
|
| rnielsen wrote: | | ...I needed to put some delays, in the Master code, to allow the Slave to have time to do it's thing... |
Isn't this situation what clock stretching is meant for ?
Even with those (unnecessary) delays in the master's code it is still easy to make further problems when your program complexity grows and the slave can occasionally serve some other interrupt while receving data over I2C. So losing a byte can happen rarely enough to cause a real debugging nightmare.
Clock stretching: (not that complicated as it seems at first glance in the datasheet)
Just set SSP1CON2_SEN = 1 in the slave, that means clock stretching enabled: the clock line will be kept low by the slave - upholding the master's sending - until SSP1CON1_CKP = 1 is set to let it go again. You do it after your code has (unhurriedly) read the data from the SSPBUF register.
Benefits: the slave can do whatever it wants any time long between each byte the master sends. All this is done automatically by hardware, and the transmission is constantly adaptively fine-tuned to the maximum speed the slave allows.
Last edited by libor on Sun May 06, 2007 3:14 am; edited 1 time in total |
|
|
Ttelmah
Guest
|
|
| Posted: Sun May 06, 2007 3:14 am |
|
|
Yes.
Clock stretching, can most definately help massively, but unfortunately, is not a complete solution when speed differences are very large. Problems arise, if (for instance), the slave 'handler', fetches the byte (and releases the clock stretching), and then takes longer than one byte time to exit the subroutine, and clear the interrupt. Now this should never apply with reasonable data rates, from the master, relative to the clock rate of the slave, but it can happen...
The problem is actually worse on SSP, where no such delay ability exists.
:(
Best Wishes |
|
|
libor
Joined: 14 Dec 2004
Posts: 288
Location: Hungary
|
|
| Posted: Sun May 06, 2007 3:25 am |
|
|
| Ttelmah wrote: | | Problems arise, if (for instance), the slave 'handler', fetches the byte (and releases the clock stretching), and then takes longer than one byte time to exit the subroutine, and clear the interrupt. |
An often overlooked possibility: You dont't have to release the clock stretching right after fetching the byte, you still have plenty of time to process it or do whatever you want in the isr still keeping the clock stretched even after you have read the data, and release clock stretching just before returning from the isr. |
|
|
Ttelmah
Guest
|
|
| Posted: Sun May 06, 2007 3:47 am |
|
|
True, but this then means to you have use your own I2C routines. The CCS versions automatically release the stretch, when the byte is fetched.
Best Wishes |
|
|
davefromnj
Joined: 03 May 2007
Posts: 42
|
| Thanks!!!! |
| Posted: Mon May 07, 2007 6:16 am |
|
|
| Ttelmah wrote: | Yes.
Clock stretching, can most definately help massively, but unfortunately, is not a complete solution when speed differences are very large. Problems arise, if (for instance), the slave 'handler', fetches the byte (and releases the clock stretching), and then takes longer than one byte time to exit the subroutine, and clear the interrupt. Now this should never apply with reasonable data rates, from the master, relative to the clock rate of the slave, but it can happen...
The problem is actually worse on SSP, where no such delay ability exists.
:(
Best Wishes |
Thanks for your help guys, I'll try out the SSPCON reg's today. I read about clock stretching, but wasn't sure if it was implemented in CCS' compiler. My data rates are rediculously slow, seeing now that CCS can "bit bang" I2C I might have picked a lower cost micro for my project, instead of the hardware I2C pic's im using... I'm sending maybe 500 bytes / second, just slow control / status signals. |
|
|
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Mon May 07, 2007 8:41 am |
|
|
Clock stretching works to tell the Master that the Slave is not done doing it's thing. The problem that I was having is that the Master would send a start, write the address and then write the command before the Slave was finished figuring out the address byte. The I2C bus would then hang and nothing would happen. Clock stretching would not have helped in this case because I didn't have control over the address compare routine built into the hardware of the Slave.
Ronald |
|
|
davefromnj
Joined: 03 May 2007
Posts: 42
|
| So then |
| Posted: Mon May 07, 2007 11:42 am |
|
|
| rnielsen wrote: | Clock stretching works to tell the Master that the Slave is not done doing it's thing. The problem that I was having is that the Master would send a start, write the address and then write the command before the Slave was finished figuring out the address byte. The I2C bus would then hang and nothing would happen. Clock stretching would not have helped in this case because I didn't have control over the address compare routine built into the hardware of the Slave.
Ronald |
It sounds like instead of fixed delays, that the master should be asking the slave for an ACK after every single i2Cwrite(), except for the last one (which should be a NACK, right???,) and the slaves should all have clock stretching enabled.
Do you guys think that might work, atleast in theory? |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
