> 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!
Reply by Michael R. Kesti●March 24, 20042004-03-24
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
Reply by Rene Tschaggelar●March 24, 20042004-03-24
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
Reply by Grant Edwards●March 24, 20042004-03-24
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!!!!
Reply by Uddo Graaf●March 24, 20042004-03-24
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