What is role of interrupt in rtos

Thread Starter

rt694157

Joined Dec 15, 2019
78
What is meaning of following paragraph

Since an interrupt handler blocks the highest priority task from running, and since real-time operating systems are designed to keep thread latency to a minimum, interrupt handlers are typically kept as short as possible. The interrupt handler defers all interaction with the hardware if possible; typically all that is necessary is to acknowledge or disable the interrupt (so that it won't occur again when the interrupt handler returns) and notify a task that work needs to be done. This can be done by unblocking a driver task through releasing a semaphore, setting a flag or sending a message. A scheduler often provides the ability to unblock a task from interrupt handler context.

rtos rovides methods for multiple tasks, In a real-time system, a task has schedulability; tasks are accepted by a real-time system and completed as specified by the task ...
 

MrChips

Joined Oct 2, 2009
30,714
Just as read.

All properly designed computer systems take advantage of interrupts, RTOS or no RTOS.

The purpose of interrupt is to preemp all processes (i.e. take control of the CPU). Smart design says to keep all interrupt handlers as short as possible. Where needed, use a semaphore (i.e. a software flag) to remind the scheduler that an interrupt has occurred.
 

Papabravo

Joined Feb 24, 2006
21,159
It means don't write a delay loop inside an interrupt routine. Honestly, I have actually seen people put all of their operational code inside an interrupt and have the main program consist of

while(!0) ;​
 

Thread Starter

rt694157

Joined Dec 15, 2019
78
Just as read.

All properly designed computer systems take advantage of interrupts, RTOS or no RTOS.

The purpose of interrupt is to preemp all processes (i.e. take control of the CPU). Smart design says to keep all interrupt handlers as short as possible. Where needed, use a semaphore (i.e. a software flag) to remind the scheduler that an interrupt has occurred.
my understanding There may be many task's but only one task will run at one time. some of them are waiting or ready to execute Interrupt may be use to block other tasks for specific time
 

MrChips

Joined Oct 2, 2009
30,714
my understanding There may be many task's but only one task will run at one time. some of them are waiting or ready to execute Interrupt may be use to block other tasks for specific time
That is simply bad design. No task should block another task otherwise you will end up with a frozen system.
Interrupts are simply used to accept and acknowledge that some event has occurred. Let the scheduler put the event in a priority queue and deal with it when appropriate.
 

nsaspook

Joined Aug 27, 2009
13,086
It means don't write a delay loop inside an interrupt routine. Honestly, I have actually seen people put all of their operational code inside an interrupt and have the main program consist of

while(!0) ;​
While that's excessive the idea that we should do almost no computing in interrupts is a bit much and is IMO driven by the limited vector/priority interrupts in see in most 8-bit controller where preemption is limited to a single H/L scheme. We should have no blocking tasks that wait and it's usually better that memory variables that need atomic updates (almost anything > 8-bits on an 8 bit controller) get computed and stored (buffered) in the context of the task that generates them. If the task is I/O driven there should be very little main program intervention.
 

bug13

Joined Feb 13, 2012
2,002
It means don't write a delay loop inside an interrupt routine. Honestly, I have actually seen people put all of their operational code inside an interrupt and have the main program consist of

while(!0) ;​
Hahaha... I have done actually that. But I think I did it with the right reason.

It was a low power design with a value line MSP430. All it does was wake up every second from the low power internal 32KHz clock via timer interrupt, read some IOs and ADC.

Depending on reading, switch on an external module and send some data to it. That's it, I thought may leave everything in the interrupt.
 

bug13

Joined Feb 13, 2012
2,002
Just happen to the project I am working on is running a RTOS, but also heavily depend on interrupt. I need interrupt to delivery "read time" performance, as the RTOS task is simply not fast enough. (The RTOS is already using a 10us tick, but I need drive some IOs at exactly 80us internal for 15us duration)

However, RTOS is not necessary for this project, but since it's there, may as well use it.
 

atferrari

Joined Jan 6, 2004
4,764
Just happen to the project I am working on is running a RTOS, but also heavily depend on interrupt. I need interrupt to delivery "read time" performance, as the RTOS task is simply not fast enough. (The RTOS is already using a 10us tick, but I need drive some IOs at exactly 80us internal for 15us duration)

However, RTOS is not necessary for this project, but since it's there, may as well use it.
If so, in spite what you say, i ask myself, why do you use that RTOS then?
 

bug13

Joined Feb 13, 2012
2,002
If so, in spite what you say, i ask myself, why do you use that RTOS then?
It's just a lot easier to use a RTOS and it's a lot more effective.

The chip we are using is CC2640r2f, it's a 3-core MCU. If we don't use the provided TI RTOS, we need to understand the working of 3 different cores, and it will take us a lot time to get it working properly. And properly there are lots of bugs as well.

But if we use the TI RTOS, it comes with all the drivers. It turns all those hair pulling moments when reading and try to understand the technical referential manuals, into just reading those searchable APIs.

In this case, using the TI RTOS is simply the right tool for the right job.
 
Top