This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: from ISR to thread
Robin Farine <rfarine@dial.eunet.ch> writes:
> Please pardon me if I missed something here but I don't see how Nick's
> pseudo-code solves the problem Henning exposed.
>
>
> If the thread just finished to handle an event (after doSomething()
> but before cyg_cond_wait()) and a second interrupt occurs. Won't the
> thread then block on cyg_cond_wait() until the _next_ interrupt occurs
> and thus not handle the event associated with the missed interrupt?
>
You're right, I was trying to make minimal changes to the original,
and got it wrong. The thread code needs to be structured more like this:
Threadcode:
{
cyg_drv_mutex_lock(mx)
data = null_data
while(1)
{
if( data != null_data )
doSomething(data)
else
{
cyg_drv_dsr_lock()
cyg_drv_isr_lock()
data = rbuf.getdata()
cyg_drv_isr_unlock()
cyg_drv_cond_wait(cond)
cyg_drv_dsr_unlock()
}
}
cyg_drv_mutex_unlock(mx)
}
By using the DSR lock we ensure that the DSR cannot get called between
testing the ringbuffer and the cond_wait. Threads can wait with the
DSR lock claimed and if there is a pending DSR when the thread waits,
it will be woken up immediately and continue.
--
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK