Handling FreeRTOS interrupts with some delay

kand123 wrote on Wednesday, July 29, 2015:

Hello everybody,

I am working on a project which consists of an embedded system with an Atmel AVR32 microcontroller and FreeRTOS.
The system has 8 fans connected to different GPIO pins and it produces separate interrupt for every fan (if it is faulty or not installed and if it is OK).
I have implemented this specification with a FreeRTOS ISR and a queue (using xQueueSendFromISR when the status change) by sending the status to a task which wait for queue reception. The task then informs the user.
My problem is that I want to delay for some time after an interrupt arise in order to be sure of the fan status avoiding rapid on/off situations.
How can I do this in FreeRTOS apart from implemented 8 tasks and checking the status of every fan with some delay?

Thanks in advance.

heinbali01 wrote on Wednesday, July 29, 2015:

Hi Kostas,

Atmel AVR32, is that a UC3 ?

If you need debouncing of 8 signals, is it still useful to use hardware interrupts?

You might also create a task that wakes up at regular intervals and let it poll for changes. Only after N confirmations of a new status the task will produce an event.

And of course, you can still use the hw interrupts for urgent signals like an over-voltage, or an electric motor control.


kand123 wrote on Wednesday, July 29, 2015:

Hi Hein,

Yes I use Atmel AVR32 UC3C.

I use hardware interrupts to get every one of the 8 signals which is not urgent signals. My problem is that I need to debounce every one of them.

How can I do this using interrupts or it is better to use one task and poll every one of them at regular interval which is not safe as these are asynchronous events.


richard_damon wrote on Thursday, July 30, 2015:

One way to use interrupts to catch the leading edge of a bouncing signal, but not get overloaded with the bounces is to disable the interrupt on the leading edge, and kick off a timer function to fire after the bounce time to re-enable the interrupt.

But, since you make the comment that you want to wait a bit before reporting (which could be done in that timer function I just mentioned), it likely means that just polling periodically may also be sufficient. This is basically a requirements trade off. The use of interrupts and a timer may give you slightly faster response, and possibly lower cpu usage (since it really does nothing in the case of no change), while periodic polling is likely simpler code.