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


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.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


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