Forums

RTOS question

Started by Uddo Graaf March 24, 2004
I heard that a RTOS always responds to an interrupt within a certain time,
i.e. the response time is predictable. However, what happens when the
interrupt or alarm is being handled and within that same time another time
critical alarm goes off? I assume it is simply flagged or an exception is
triggered which sounds a siren or something because it can't preempt the
currennt handler


On 2004-03-24, Uddo Graaf <u.NOSPAMgraaf@DELETETHISchello.nl> wrote:

> I heard that a RTOS always responds to an interrupt within a > certain time, i.e. the response time is predictable.
True -- although it's only predictable in combination with a particular appliction.
> However, what happens when the > interrupt or alarm is being handled and within that same time another time > critical alarm goes off?
Typically, it doesn't get handled until the handler for the first one has finished. However, if you want, you can nest interrutps so that the second interrupt is handled in the "middle" of the first interrupt's handler.
> I assume it is simply flagged or an exception is triggered > which sounds a siren or something because it can't preempt the > currennt handler
No. It's either handled immediately, or the interrupt stays pending until the first handler finishes, at which time the second interrupt is handled. -- Grant Edwards grante Yow! My face is new, my at license is expired, and I'm visi.com under a doctor's care!!!!
Uddo Graaf wrote:

> I heard that a RTOS always responds to an interrupt within a certain time, > i.e. the response time is predictable. However, what happens when the > interrupt or alarm is being handled and within that same time another time > critical alarm goes off? I assume it is simply flagged or an exception is > triggered which sounds a siren or something because it can't preempt the > currennt handler
The responsetime can be guaranteed only when the handlers are known and especially made for the purpose to be fast. This means whatever interrupts appear, they may not delay the interrupt in question beyond the responsetime. This means there cannot be an endless series of pagefault & filesystem & User right exception & virtual hardware stuff slowing the response. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Uddo Graaf wrote:

>I heard that a RTOS always responds to an interrupt within a certain time, >i.e. the response time is predictable.
Not necessarily.
> However, what happens when the >interrupt or alarm is being handled and within that same time another time >critical alarm goes off? I assume it is simply flagged or an exception is >triggered which sounds a siren or something because it can't preempt the >currennt handler
The system behaviour depends on the CPU being used and on how it is programmed, just as it does when not using an RTOS. If the CPU supports nested interrupts then the second interrupt might preempt the first. Otherwise, the second interrupt is serviced when the first's ISR completes. RTOSes provides tools, such as priority based multitasking and inter- process communications, to ensure that critical processes get the best chance to execute prior to their deadlines. If well implemented, they do so in an optimal manner, but they are not magic and must live within the confines of the hardware just as system implemented with RTOSes must. -- ======================================================================== Michael Kesti | "And like, one and one don't make | two, one and one make one." mkesti@gv.net | - The Who, Bargain
"Michael R. Kesti" wrote:
> Uddo Graaf wrote: > >> I heard that a RTOS always responds to an interrupt within a >> certain time, i.e. the response time is predictable. > > Not necessarily. > >> However, what happens when the interrupt or alarm is being >> handled and within that same time another time critical alarm >> goes off? I assume it is simply flagged or an exception is >> triggered which sounds a siren or something because it can't >> preempt thecurrennt handler > > The system behaviour depends on the CPU being used and on how it > is programmed, just as it does when not using an RTOS. If the > CPU supports nested interrupts then the second interrupt might > preempt the first. Otherwise, the second interrupt is serviced > when the first's ISR completes. > > RTOSes provides tools, such as priority based multitasking and > inter-process communications, to ensure that critical processes > get the best chance to execute prior to their deadlines. If well > implemented, they do so in an optimal manner, but they are not > magic and must live within the confines of the hardware just as > system implemented with RTOSes must.
It may help to think of it this way. All processes run at some priority, which may even be dynamically modified. Each physical interrupt is associated with some process, which is normally not ready. An interrupt makes the associated process ready and launches the dispatcher, which selects the highest priority process and runs it. One such process may even be a timer process. All processes may mark themselves as not-ready, and as waiting for some event, and call the dispatcher. These operations involve some minimum time period, normally known as latency. Now, with this shell, your task, should you decide to accept it, is to design a set of processes that meet some timing criteria, such that you can guarantee maximum delays between certain events and responses to those events. Note the word guarantee, which is the hallmark of a RTOS. But that guarantee depends on the tasks that you give it. The RTOS is just the shell. If you give it an impossible set of tasks, it will fail. A normal OS will probably just slow down, and become generally sulky and unresponsive. Some are highly likely to crash. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
does any one port ecos-RTOS to arm board?



----
http://arm.web7days.com




In article <c4013e$t3a2@imsp212.netvigator.com>, USB wrote:
> does any one port ecos-RTOS to arm board?
Yes. -- Grant Edwards grante Yow! The PINK SOCKS were at ORIGINALLY from 1952!! But visi.com they went to MARS around 1953!!