Best Known Method (BKM) for Multiple Interrupts

[john.ma]

Good Morning People,

I have a question related to multiple interrupts (5-6), potentially triggering simultaneously.
Some of them are time-critical and 2 of them occur quite regular (3-5ms) Occasionally, a burst of SPI interrupts will occur as well.

In terms of program design whats the best approach to deal with this kind of design?

I searched the forum but I didnt find anything specific, had a look at the interrupt levels (made a matrix with INT min/max duration, freq. to assign levels) but wanted to see what other people experienced/suggest.

Thanks,
John

List of INTs,
Input Compare
Output Compare (3)
SPI
Timer

[Ttelmah]

Seriously, use another chip....
_Nothing_ can occur 'simultaneously' on a single core processor.
Anything you do with matrixes of times, is likely to take longer than just handling the events.
Key things are to reduce the time in each handler, and the overhead (if you can keep each handler very short, using few resources, then you can speed up the entire response, by not saving registers that the interrupts don't use). So, custom int_global handler, and your own dispatcher. However it is still not going to be 'simultaneous'.

Best Wishes

[John P]

It doesn't fit every situation, but my favorite way to write a program is to have just a single interrupt, based on a fast timer. Then anything that has to be done, is done in response to polled flags within that interrupt, or back at main() level in response to flags set in the interrupt. What I like about this is that you know, absolutely without fail, that any clock function is operating at the desired rate and isn't being blocked by another interrupt. I often need a serial port running at 115.2KB, so a rate I often use for the interrupt is 13KHz, which guarantees that any arriving character can be caught and buffered. But sometimes I've wanted an additional transmit-only UART at 9600 or 19.2K, and then I'll push the rate up to 19.2KHz so I can bit-bang the data easily (CCS's software UART isn't usable this way).

However, if you want the ultimate in responsiveness, like catching every transition from an encoder, you'd have to have an interrupt per operation and be sure not to block it. But most of the time, that's not necessary, and if you give the encoder what it needs, some other part of the system is failing. Generally just using a timer interrupt works well.

[Mike Walne]

You don't tell us how time critical.

What is the maximum time error you can tolerate for each of your events?

As you've already been told, two things can't happen simultaneously on a PIC, so something has to give.

Mike

[asmallri]

[Mike Walne]

OK. I was stretching things a little.

Just trying to extract a bit more information from the OP.

Mike

[john.ma]

The Input Capture and Output Compare aren't too difficult to deal with. As long as they get serviced before the next event which is every 10ms for OC and PPS (1s) for IC... the value is stored and HW beneath will continue operating.

Timer 2 for IC and timer 3 for OC operate from the same clock but at different periods. These are probably the most 'critical' as the ref-clock runs at 20MHz thus overflows every 3ms or less (depending on timer period). However, its literally increase TMR overflow counter and leave...

Im using the MSSP in standard mode for SPI (without FIFO) therefore this has to be serviced before the next packet is sent. 13 8bit packets are sent at a rate of 4MHz.

The PIC is operating at 32MHz internally, thus if I assume an interrupt is triggered every 1ms then I have 16000 cycles (Fosc/2) between these ints which is good.

Ive used a straight forward implementation by just assigning priority flags to timer2 and timer 3 and SPI atm and it seems to be fine but I will test it over several hours to see if there is any conflict.

Regards,
John

[RF_Developer]

Just what are the SPI latency requirements?

With SPI it the requirements of the slave that dictates the maximum bit rate it can run at. More or less any software slave implimentation is going to be slower than a hardware, or mainly hardware version: often a lot slower.

Essentially, the maximum bit rate is determined by the length of time the slave needs to get its data ready: the bit rate should be such that the time to send one byte is greater than the maximum time, in that case including all latency and delays caused by other ISRs, for the software to do its thing.

It sounds like this is an SPI slave. If its a master then there's no problem as the master can send bytes whenever it needs to (as long as the timing requirements of the slave are met), and the bit rate is irrelevant. If it IS a slave, then the choice of hardware is largely dictated by any system level requirements. Put simply, if you MUST run at 4MHz then you have a problem. 4MHz is respectably fast for many hardware SPI devices (memories, which are something of a special case, are often faster but they generally work in some sort of burst or page mode when transferring data). Its very fast for a mainly software implemented SPI slave as when reading from the slave, each next byte needs to be ready in just 2us, i.e. one byte time. This is even true if its doing some longish term function such as writing to a eeprom (or the device IS an eeprom) as a slave is expected to implement a status scheme whereby the master can interrogate the slave, at the full SPI speed the slave allows, with no additional delays, and read whether any previous operation, sucha as a write, is in progress or has completed.

On the other hand, there is no SPI standard and what's "expected" may well not be what happens in many systems.

Generally though, with SPI, the master has to run at the speed the slave can cope with. Its the slave that specifies the maximum speed its happy with: the master simply has to respect that. Some heavy handed systems engineers may try to dictate SPI rates on to slave implementors, but that really ins't a good way to develop systems as it will often place an unrealistic, and frankly unrequired speed limit on the slave which is therefore much harderand expensive to develop, and increasing production costs. E.g. requiring an FPGA rather than a simple PIC. Why? Simply because someone insisted the SPI had to run at 4MHz when 100kHz would have been fine. Also SPI doesn't need to run at the same speed for all devices, though its generally convenient and simpler when it does. While it is possible to run CCS C SPI at varying speeds by direct manipulation of the MSSP registers, the compiler built-in support is intended for a "set once and forget" scenario.

RF Developer

[Ttelmah]

As RF_Developer says, the critical thing is the latency of slave responses.
If this is a slave _returning data_, then the first response byte must be loaded before the second byte starts to clock. This is one of the hardest things to ensure....

For the comments it looks like this is a DsPIC?.

If so, then use the DMA for this. In a real sense, that is what it is 'there for'.....

Best Wishes

[john.ma]

Thanks for the advice guys, I can take that on-board.
I'll monitor the system and see if there are any conflicts and then tune appropriately.
Its a PIC24FJ128 so unfortunately no DMA, but I think it'll do.

Thanks everyone,
John