Multipal interrupt

Kernel
1

Hi,

If I have three interrupt on my controller one is RS232, RS485 and Timer, I do’t want to miss all three interrupt.

Is there any way to handle all three interrupt, all three interrupt can occur at same time of instant

2

In the old days, when processors were slow, we had this problem of “missed” interrupts.
Nowadays, no interrupts shall be missed.
My favourite way of handling interrupts is as follows, symbolically:

volatile uint32_t ulISRStatus;

void myISR()
{
    ulISRStatus = get_isr_status();
    clear_isr_status();
    wakeup_task();
}

Sometimes status bits are cleared when you ready them. Sometimes you must write either a 1 or a 0 to clear them. That depends on the platform/peripheral.

If you do not clear a status bit, for which you have enabled an interrupt, the interrupt will keep on trigger ISR’s.

Waking up a task can be done in many ways: task notification, a queue, a ( counting ) semaphore.
Remind that the use of FreeRTOS API’s during an ISR is very limited: only API’s can be used that have ‘FromISR’ in their name.

One example is:

void wakeup_task()
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    /* Notify a task, xHigherPriorityTaskWokenmight become true. */
    vTaskNotifyGiveFromISR( xTaskHandle, &xHigherPriorityTaskWoken );
    /* Yield after the ISR is ready. */
    portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
3

Generally, interrupt are ‘remembered’ until you act on them, and you tend to have some reasonably defined period you have to service the interrupt. For a serial port, you tend to have at least 1 character time to read out the character before you lose things. (Some poorly designed serial ports might give you more like a bit time). Timers will also tend to have specifications from hardware or software requirements of how long you have to respond to them. Sometimes you can’t, and then you have a tougher issue, needing to change your design in some way to meet the requirements, or accepting that there are cases when you will miss some data, and need to have some sort of error recovery.

Typically, the ISR to handle these interrupts will be very short, doing just actions needs to acknowledge the interrupt and possibly save the data from it. You will normally prioritize the interrupts so those needing quicker responses are given higher priorities and those that need a more complicated ISR given a lower priority. Generally, you can organize things so that you can be sure that all interrupts will be serviced within the time frame you have for it.