Stefano,
As one who has been through this problem before (a few times), let
me offer some comments.
> How can I set ISR priority level so that the interrupt handler can
> complete before thread p awakes ?
I can not think of any way that this can be done. The ISRs in
RTLinux run within the context of the process which was running when the
interrupt came in. Thus there is no way to be sure that the interrupt does
not get pre-empted by the scheduler, unless you are certain that the
interrupted task is the only computable process.
I am sure, however, that if you are trying to use pthread_suspend_np
from an ISR, you are probably doing something the hard (very hard) way. In
general ISRs wake things up, not put them to sleep.
Perhaps if you provided some details of your application I/we could
help you with your design.
> With RTLinux 2.0 it seems I can't call pthread_kill...is it right ?
?? 2.0 ?? First bit of advice, upgrade to 3.0 - many many many
fixes.
Also, as an aside, when you do a pthread_wakeup_np from an ISR, you
have to keep in mind that the ISR will probably be pre-empted immediately.
Thus you should get all of your hardware tweaking, etc. that needs to be
done in a highly-deterministic ISR sort of way done *first*, before calling
the wakeup. The system will go and serve the woken process and will return
to call the IRET in the ISR when that process goes back to sleep. This is,
of course, assuming that you have all of your priorities set in a "normal"
manner.
This sort of "odd" quasi-inverted mechanism was implemented to
prevent having to call the scheduler (expensive) with every interrupt. Thus
systems with interrupt driven serial I/O, for example, can avoid a bazillion
calls to the scheduler.
Regards,
Steve
-- [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/
