Electronic – Clearing/acknowledging of level triggered interrupts

interruptslevel

I am confused with the clearing/acknowledgement of level triggered interrupts in an SoC. When an interrupt is level triggered should the clearing be done in the interrupt controller or the bus controller (spi controller,gpio controller) or in the peripheral device itself. If I have to clear in the peripheral device itself then I should be connecting a line to from my SoC core to the device, correct? Could somebody also give an example say of SPI device using level triggering?

Best Answer

With an edge-triggered interrupt, you can safely exit the ISR right away without any further action because the interrupt will not be triggered until the interrupt pin goes low (or high as the case may be) again.

With a level-triggered interrupt, it is assumed the peripheral causing the interrupt does not reset the level going into the interrupt pin by itself, since it can't know the latency of the ISR). If this interrupt did work this way, and the microcontroller was set up to latch the condition of the signal going high or low, this would just be the same as an edge-triggered interrupt.

So the microcontroller must cause the level to be reset, either within the ISR or in the base level following the ISR.

Depending on the peripheral, there might be two ways to reset the interrupt signal. One is when the peripheral has a specific pin for this purpose, typically called an interrupt acknowledge. Pulsing this lead high to low and back (or vice vera) resets the interrupt level. This is the only method available if the microcontroller has no interface available to manipulate registers inside the peripheral.

The other way to reset a level-triggered interrupt, which is much more common, is to reset (or set) an interrupt acknowledge bit in one of the registers of the device. This bit would be set by the peripheral itself when the interrupt is generated, and reset by the microcontroller (or vice versa). Obviously this only makes sense if there are internal registers that can be addressed by the microcontroller, via either I²C, SPI, parallel bus, or other means. This resetting of a interrupt flag is almost always the way microcontroller acknowledges an interrupt generated by a peripheral located within itself.

The problem with the second approach, is performing an SPI or I²C transfer takes time, and you may not want to spend that much time in your ISR. So you can disable the interrupt that was triggered and set a flag. As soon as you exit the ISR, and enter some sort of idle condition, then based on the flag being set, you can then perform the I²C or SPI transfer to reset the interrupt flag in the peripheral, and then re-enable the interrupt. If you are using a multi-tasking operating system of some type, you can generate an event from within the ISR or whatever it needed in you OS to wake up a task to perform this operation.

If you can't disable just the interrupt that was triggered, and you must disable all interrupts, this obviouls will have a much more drastic effect on your system, and it might be preferable just to do the I²C or SPI communication within the ISR and be done with it.

So, if it is so much trouble to handle level-triggered interrupts, why have them in the first place? Because it allows one to have several different peripherals tied to the same interrupt pin, and be able to identify where the interrupt came from.

Say you have only one external interrupt (called Not_Interrupt_In (since I can't use \$\mathsf{\small \overline{\text{Interrupt In}}} \$ in CircuitLab) and two peripherals that can each generate level-triggered interrupts (Not_Interrupt_0 and Not_Interrupt_1). You tie the interrupt outputs of each of these to the same external interrupt pin through a diode. It is assumed they are all configured as open-drain, that is, the normal condition if a logic 1, and when an interrupt occurs, the output goes to logic 0. (If one or both pf the interrupts pins of a peripheral is not open drain, just omit the corresponding resistor.)

enter image description here

The diodes create an OR gate; it may seem they are backwards but remember we are dealing with negative signals (0 = asserted). I've verified the circuit operation on CircuitLab.

So either interrupt source will cause the external interrupt line on the microcontroller to go to 0, generating an interrupt. Meanwhile, each interrupt line has its own input to one of the ports on the microcontroller, in this case Port A bits 0 and 1. So when the interrupt occurs, the ISR can look at port A and determine which peripheral generated the interrupt.

Note this can't be done with edge-triggered interrupts, since it can't be assumed the interrupt line is still asserted by the time the ISR gets control, so a poll would not work. One could externally feed the edge interrupts into latches, which could be polled, but they would need to be reset by the ISR, and there are some nasty race conditions which have to be avoided.

Related Solutions

Electronic – dsPIC33, SPI slave, and Timer1 interrupts. What happens

Normally you would set up the SPI peripheral once, then leave it on. The extra handshaking you are doing is preventing you from using the hardware to its full capability. Also doing a busy wait for the master to assert slave select is a bad idea if you ever want the processor to do something else.

Since you are transferring 16 bits of less per message, I would just let the hardware take care of it. Then you can monitor the SPI interrupt flag to determine when new data has been received from the master. If you need to slow down the master for flow control reasons, I would do that outside of the SPI message. I suspect the interrupt is adding latency to your home grown handshaking scheme, and something somewhere isn't quite right and can't tolerate that latency. That's assuming of course that the interrupt doesn't try to touch the SPI hardware or any of its I/O lines.

Electronic – Handling interrupts during device communication

You could implement a small state machine like this:

// global, volatile (accessed from ISR) variable 
// (should also be 1-byte to prevent multibyte access issues on 8-bit system)
volatile CurrentState;

main() {
    Spi_Init();
    CurrentState = StartMeasurement;

    // your main loop
    while(true) {
        // other main processing here            

        // spi processing
        switch (CurrentState) {
           case StartMeasurement:
               Spi_StartMeasurement();
               CurrentState = WaitForResult;
               break;
           case WaitForResult:
               // nothing todo -> no blocking main -> this switch is just for clarification and can even be removed
               break;
           case ResultReady:
               Spi_GetResult();
               CurrentState = StartMeasurement;
               break;
           default:
               // CurrentState was set to invalid value -> error handling
               break;
        }
    }
}

ISR_ResultReady() {
    if (CurrentState == WaitForResult) {   // this should always be true but its cleaner to check it
        // signal main that result is ready
        CurrentState = ResultReady;
    }
}

I hope you get the idea. There are cleaner, more abstract ways to do this, but for small applications it also overcomplicates things.

Best Answer

Related Solutions

Electronic – dsPIC33, SPI slave, and Timer1 interrupts. What happens

Electronic – Handling interrupts during device communication

Related Topic