I2C slave interrupt problem

[rmash]

Kind Embedded Programmers,
i'm using a master/multi-slave arrangement of pics to develop several multiphase PWM waveforms. The master is an 18f8722, and the slaves are 18f458s. I don't want to go into the nitty gritty about the PWM generation, but the idea is that the master sends a requested PWM percentage and the slaves individually generate the waveforms with timer interrupts. This waveform generation is working fine, but I'm having problems with the timer interrupts conflicting with the I2C slave interrupt.(int_ssp)
So, at this point I can try to further trim the timer ISR execution time so as to minimise the liklihood of a ssp interrupt during execution of a timer isr. Or, I could implement the I2C slave without an interrupt. I'm not sure if that is feasible. Or, I could convert to SPI which wouldn't require an interrupt in the slave code.

I can post code and such, but first off, does if sound as if i'm missing any pieces of the picture here? Is an interruptless I2C slave feasible?

Thanks very much for your collective input.

[PCM programmer]

You need to determine the required interrupt response time for an i2c
slave interrupt -- then make sure the Timer interrupt takes less time
than that.

The Timer interrupt duration is the sum of the Timer isr execution time
and the time required to execute the CCS interrupt dispatcher code
(to both enter and exit the Timer isr).

The CCS Ex_Slave.c example programs the SSPCON1 register so that
interrupts are not enabled for Start and Stop bits. You only have to
consider interrupts for address match and incoming bytes.

If your SCL clock is 100 KHz, then the bit time is 10 us. I looked at
the timing diagrams in the i2c slave section of the 18F458 data sheet.
It looks like you have 8 bit-times to respond to the i2c interrupt.
That would be 80 us. Ideally you would respond faster than that,
to allow some margin.

I compiled the Ex_Slave.c program and added a Timer0 isr. I then
counted up the number of instructions in the interrupt dispatcher code.
Assuming that the Timer is given priority (with a #priority statement)
and therefore it comes first, I count 43 instruction cycles for the
dispatcher code (to get in and out). The Timer isr has 3 instruction
cycles at the end, to jump back to the interrupt dispatcher exit code.
So that would add up to 46 cycles of overhead. There is also the
peripheral interrupt latency, which looks like its 3 or 4 instructions.
So the net overhead is approximately 50 instruction cycles.

If you're running the slave PICs at 4 MHz, each instruction takes 1 us.
In that case, you've already eaten up 50 us, just for the overhead to
get in and out of the Timer isr. You only have 30 us left in the timing
budget to execute the Timer application code. You didn't say what
code you've got in there. Hopefully it's short.


There are a few solutions:

1. Increase the oscillator speed of the Slave PICs. You're using
18F458s. You could run them at 40 MHz by using the PLL, if required.
Even if your current crystal is 4 MHz, you could enable the PLL and
run them at 16 MHz. It may be that you don't want to use the PLL
for reliability reasons. It does add complexity to the PIC's operation
and therefore adds risk to reliability. So maybe just use a 20 MHz
crystal.

2. Slow down the i2c clock speed on your master. I2c doesn't have
to run at the official speeds of 100 KHz or 400 KHz. You can run it
at 40 KHz or even much less than that, if you want to.

3. Shorten the application code inside your Timer isr. I assume
you have done this already.

There might be other things you could do with using higher speed
interrupts. I haven't done that before, but there are other people on
the forum that understand it completely.

[Guest]

PCM programmer,
Thanks for your reply and your time. I decided to move over to SPI, so as to remove the communication interrupt from the slaves.
i"m finding that this works pretty well. Still having some intermittent failures. Around 1 in 36000 three byte transfers gets off the beaten track... I'm working to see how i've managed to diverge from the SPI specs now. I may just implement an acknowledge system to check for errors.

The pics are all running at 40mhz. (incidently) And the interrupts timer interrupts range from 3-5uS execution time, excluding dispatching code, so a bit more perhaps. This means that most of the time the slave pics are doing nothing... Not a big deal I guess.

I'll reply to this thread later if I conclude this activity soon. Again thanks for your input.
rmash