ARM中断处理程序

Question

First to say that I already read this and could not understand or get a clear answer. I am an AVR guy trying to learn ARM. I am programming the ATSAM4LC2AA from ATMEL. When I encounter the ISR handler should I disable global interrupts? And if so is this the correct piece of code?

void USARTx_Handler(void)
{
    /* Disable interrupts */
    irqflags_t flags = cpu_irq_save();

    /* Read USART Status. */
    Do_small_task();

    /* Enable interrupts */
    cpu_irq_restore(flags);
}

Answer 1

The basic gist of the linked answer is "in the ARM M-profile architecture, you usually don't need to do anything". Taking any exception automatically masks any other exceptions of equal or lower priority. Returning from the exception handler automatically restores the previous state. If you find yourself wanting to mask higher -priority exceptions within a lower-priority handler, start by considering whether you've got your priorities set appropriately in the first place - there are occasional valid reasons for doing so, but if you don't already know why you need to, you don't need to.

Answer 2

cpu_irq_save() normally doesn't disable interrupts, it just returns the state of the flags. The current and all lower priority interrupts have already been disabled. cpu_irq_restore(flags), restores the flags. I'm not sure why these calls would be needed unless USARTx_Handler() is changing the state of the flags. Usually there is some kernel (operating system) code that has already saved "context" before calling USARTx_Handler().

If this isn't a nested interrupt, then the ARM changed from thread mode to handler mode to handle the interrupt. The typical kernel (operating system) code outside of USARTx_Handler() that handles the actual interrupt (exception) calls USARTx_Handler(), then when USARTx_Handler(void) returns, it's the kernel code that would restore the ARM to it's prior state, typically back to thread mode (unless it's in a nested interrupt state).

In the case of a multi-threaded kernel (like some version of a RTOS), it may include functions that can be called from an interrupt handler that eventually result in a context switch to a different thread when the interrupt function returns.

update - based on Tedi's comment, cpu_irq_save() is also disabling interrupts (apparently saving the flags before disabling interrupts). The function name could have been better, cpu_irq_save_and_disable_irq(), but perhaps too long. As long as the documentation shows how these functions are supposed to work, the name isn't that important.

This creates timing windows, at anytime after USARTx_Handler() is called but before cpu_irq_disable actually disables interrupts, a higher priority interrupt could preempt USARTx_Handler(). Also, at anytime after interrupts are (assuming here) enabled by cpu_irq_restore(), but before USARTx_Handler() returns, a higher priority interrupt could also preempt USARTx_Handler(). But at least you know between cpu_irq_save() and cpu_irq_restore() that interrupts are disabled.

What if you didn't want USARTx_Handler() to disable higher priority interrupts? Are there any special calls needed for that?

Since I don't know anything about the kernel / RTOS being used here, I'm not sure of the implications of implementing interrupt handlers in this manner. One issue is if the kernel supports nested interrupts being able to call kernel functions such as ones that result in a context switch when the interrupt chain returns to thread mode from handler mode.

There's also the issue of how NMI (non maskable interrupt) is handled. Some RTOS's don't handle this, so the solution is for an embedded device to set a special hardware based interrupt (IRQ) in the NMI handler, and then just return from the NMI, where the special interrupt handler completes the sequence started by the NMI. Other RTOS's can handle system calls from nested IRQ and/or NMI.