Arnaud Westenberg wrote:
>
> Stuart Hughes wrote:
>
> > One point I want to make is that there is a good reason why often people
> > would choose to have an ISR wake up a real-time task to carry out the
> > bulk of a set of processing. On most other real-time operating systems,
> > the task that gets woken from the ISR runs at a lower privilege level
> > than an ISR (in terms of machine state), also interrupts are normally
> > enabled. This means that the task can be pre-empted by other real-time
> > tasks and also interrupted. In the Linux (hard) real-time
> > implementations (RTL/RTAI) this is not currently true, as I believe that
> > the task/thread runs at the same machine privilege level as the ISR.
>
> This is not correct, I asked this question recently. Here's the question
> and victor's reply:
>
> Q: Does a "hard" handler stop a RT thread? (I would say yes) How are the
> Q: "priorities" between hard handlers and RT threads determined by
> RTLinux?
>
> A: Hard handlers preempt anything that is not running with hard
> interrupts
> A: disabled. There is no other priority mechanism.
>
> So RT threads will be interrupted by the handler.
>
Hi Arnaud,
The real question is if I have an ISR whos only task is to wake up a
thead, what happens:
a) enter ISR, wakeup thread, thread code runs, return to ISR, exit ISR
or:
b) enter ISR, wakeup thread, exit ISR, thead code runs.
I'm saying that b) is more conventional, and I would like to have this
facility available.
Regards, Stuart.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
