Victor / Dyd,
> > When a key is typed , a rt thread which is blocking waiting
> for the key
> > should be wakeup. The wakeup should be done by first
> changing the thread
> > state to RTL_THREAD_READY then calling rtl_schedule or
> rtl_reschedule.
Or you could use the user API mechanism
(pthread_suspend_np()/pthread_wakeup_np()) provided for exactly this
purpose. The key is to remember to do all of the cleanup of the hardware
before calling pthread_wakeup_np() in the ISR. The reason for this is that
the task which was sleeping on the pthread_suspend_np() call will become the
highest priority computable task and will preempt the completion of the ISR.
Fortunately, the RTL scheduler takes you out of ISR context appropriately,
so you are not blocking other interrupts, etc.
This mechanism is a little odd, but reasonable to promote efficiency
in those circumstances that Victor mentioned in his reply. Just make the
pthread_wakeup_np() call the last call in the ISR before the return and
everything will be just fine.
> > I forgot to call rtl_schedule. I made this mistake because
> I've assumed that
> > schedule will be done when irq returned. This is the way Linux do.
> >
> > So the question is that if it is reasonable to let rtlinux
> do rtl_schedule
> > when it returned from a realtime interrupt?
If you find yourself calling rtl_schedule you need to take a look at
what you are doing with regards to priorities, etc. The programmer (other
than the RTOS programmer) probably shouldn't ever need to call rtl_schedule.
Can anyone think of a situation where this is required?
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/
