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.
> So
> for real-time Linux it is currently less important than on other RTOS's
> to make the ISR/task distinction, but things may change in the future,
> so keeping this in mind may help to produce a design that will be more
> conventional:
>
> a) if real-time Linux changes
> b) if you port to other real-time operating systems
>
> 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/
-- [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/
