Re:add user interrupts on future device
With an event driven system, you could process the event in the ISR, instead of setting a flag and polling later in the thread. This seems like a great idea at first sight, because you get zero latency between interrupt and 'task' execution, and the NVIC does all the pre-emptive scheduling for you, based on the priorities of the interrupts. Unfortunately the downside is that the ISRs take a lot longer to execute, and hence block other lower priority interrupts (i.e. tasks). This could be a problem if your system has to respond to several different interrupts at high frequencies.
Comparing RTOS to non-RTOS systems :-
Ignoring scheduling and overheads for now.
Terminology -
Event (E) = interrupt, exception, trigger, stimulus
Action (A) = task, process, module, function, code block
Time (T) = time duration of Action (continuous)
Lets have a system with 10 Events E1 .. E10
E1 is highest priority, E10 lowest.
example1:
E1 .. E5 all occur approx same time.
Delay Time(D) before actioning E5 =
D:RTOS = T1 + T2 + T3 + T4
D:non-RTOS = x + T1 + T2 + T3 + T4
where x is time for current action to complete
For a balanced system T1 = T2 ... = T10 = 1ms
D:RTOS = 4ms
D:non-RTOS = 4-5ms
For a unbalanced system T1 = T2 ... = T7 = 1ms
T8 = T9 = T10 = 5ms
D:RTOS = 4ms
D:non-RTOS = 4-9ms
So which is real-time?
The RTOS may be able to smooth out the bumps in unbalanced systems, otherwise a simple non-RTOS probably out-performs the overheads/complexity of an RTOS.
What's the difference between a 'background' task and any other 'task'? Priority?, Time? ...
login or register to reply
|
