This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: from ISR to thread


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?

Robin

Nick Garnett wrote:

>Schmidt Henning Larsen <HenningLS@danfoss.com> writes:
>
>>Hi
>>
>>I'm looking for some of the advantages and disadvantages there is in Ecos.
>>One of the great constrains I've found I eCos is that it is difficult to get
>>continues data from ISR to a thread.
>>I will here describe what I think is the problem, and I hope someone will
>>give it a comment.
>>
>
>[snip examples]
>
>>My conclusion is: 
>>ECos doesn't have a useful synchronization mechanism, in situations where we
>>will allow interrupts to appear, while we are processing data from previous
>>interrupts on the same source/device.
>>
>>I hope someone can tell me if I'm wrong.
>>
>
>The way I intended things to work in ecos is as follows, using your
>pseudo code:
>
>Mutex: mx
>Condition variable: cond
>Hardware data: hw
>Ringbuffer: rbuf
>
>Threadcode:
>{
>  cyg_drv_mutex_lock(mx)
>  while(1)
>  {
>    cyg_drv_cond_wait(cond)
>
>    cyg_drv_isr_lock()
>    data = rbuf.getdata()
>    cyg_drv_isr_unlock()
>
>    if( data != null_data )
>        doSomething(data)
>  }
>  cyg_drv_mutex_unlock(mx)
>
>}
>
>ISR code:
>{
>  cyg_drv_isr_lock()
>  rbuf.putdata(hw.data)
>  cyg_drv_isr_unlock()
>
>  cyg_drv_interrupt_acknowledge()
>
>  return cyg_isr_call_dsr
>}
>
>DSR code
>{
>  cyg_drv_cond_signal(cond)
>}
>
>
>I've added the mutex operations since cond_wait does not work unless
>the mutex is already claimed.
>
>Using the isr_lock makes the ring buffer a critical region shared by
>the thread and the ISR. The head/tail pointers in the ring buffer
>already contain the same information that the semaphore counter
>would. So using a semaphore would be redundant. The only real change
>in semantics is to allow the ring buffer to indicate that no data is
>available, to cope with the possibility of spurious wakeups from
>cond_wait. Of course you can, in some situations, implement the
>ringbuffer so that the ISR locking is unnecessary, but I'm not
>assuming that.
>
>Note that the masking and unmasking of the interrupt between the ISR
>and DSR is not really necessary, so long as accessing the hardware
>cancels the interrupt condition. It is only done in the serial drivers
>because the actual hardware access is done in the DSRs there.
>
>Hope this helps.
>



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]