| View previous topic :: View next topic |
| Author |
Message |
davefromnj
Joined: 03 May 2007
Posts: 42
|
| 2 PICs, I2C + 1ms Timer0 problems |
 Posted: Wed Jun 06, 2007 4:16 pm |
 |
|
Hello All,
The setup:
1 PIC16F677 running at 4MHz. (Slave)
1 PIC18F65J10 running at 4MHz with internal 4x PLL = 16MHz. (Master)
I2C comms are good, data does get passed with regular test code.
I2C data rate in all cases is set to "slow."
I2C comms appear to work properly between these two chips.
The issue is the following:
The 18F65J10 Master needs to keep 1ms accurately.
The 16F677 Slave doesn't really need to keep accurate time.
The 18F65J10 occasionally gets locked up----for up to 20ms, waiting for a response from the 16F677.
Questions:
#1 Are ANY of the I2C slave commands BLOCKING in this setup? Can the slave tie up the Master so that the master cannot process its instructions in the 1ms ISR ?
#2 If so, any way around this, so that the commands within the 1ms timer_isr will be processed, every 1ms? |
|
 |
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Wed Jun 06, 2007 5:49 pm |
|
|
In I2C communications, the Slave has the ability to hold the SCL line low while it's processing whatever command you have sent to it. This tells the Master that the Slave is busy and keeps the Master from sending any more commands/data until the Slave is finished doing it's thing. If your Master code gets 'hung' during this time you might want to find out why the Slave is taking so long or make your Master code so it isn't required to wait around for the Slave to finish ho-humming around.
Ronald |
|
|
davefromnj
Joined: 03 May 2007
Posts: 42
|
| Hello |
| Posted: Thu Jun 07, 2007 5:28 pm |
|
|
| rnielsen wrote: | In I2C communications, the Slave has the ability to hold the SCL line low while it's processing whatever command you have sent to it. This tells the Master that the Slave is busy and keeps the Master from sending any more commands/data until the Slave is finished doing it's thing. If your Master code gets 'hung' during this time you might want to find out why the Slave is taking so long or make your Master code so it isn't required to wait around for the Slave to finish ho-humming around.
Ronald |
The master's code is structured around a taskscheduler. The taskscheduler is based on Timer0 expiring every 1ms. The problem is that apparently the compiler's i2c_read() and i2c_write() functions do not allow the Timer0_isr to interrupt the response from the slave unit.
So for whatever reason (maybe there's a good one) i2c_read() and i2c_write() have a higher priority than timer0_isr.
I'm going to try to speed up the slave's clock so that it processes the commands / sends back data faster. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
