RTEMS device driver and interrupt

Fernando RUIZ CASAS correo at fernando-ruiz.com
Thu Apr 11 21:02:59 UTC 2002


Another posibility is to operate in two modes.
Locking and Not Locking,
The Write routine asks for the open mode and if the file (device) is opened
with LOCK flag the routine waits until the buffer is empty.
In NOLOCK mode the write only waits if the interrupt buffer is full.
In order to make a good software my experience says that the best choice
is the last.
You can make a ioctl() device in order to wait the buffer empty too.
Really the last is a flush() the transmision buffer.
If your buffer has the in,out pointers and a very used counter variable
you only need the semaphore to lock when  you inc() or dec() the counter
buffer. It's a shared and volatile variable.

Don't waste more semaphores to make this.
It's a classical buffer for the producer and comsumer.

BRGDS

Fernando RUIZ CASAS
home: correo at fernando-ruiz.com
work: fernando.ruiz at ctv.es

> -----Mensaje original-----
> De: Joel Sherrill [mailto:joel at OARcorp.com]
> Enviado el: jueves, 11 de abril de 2002 20:34
> Para: Pattara Kiatisevi
> CC: 'RTEMS Users'; oggonachip at yahoogroups.com
> Asunto: Re: RTEMS device driver and interrupt
>
>
>
>
> Pattara Kiatisevi wrote:
> >
> > Hi,
> >
> > I have a conceptual problem while writing a device driver for sound.
> > The idea is that the write() function to this device should block until
> > all the music sent has been played. I plan to:
> >
> > -have the audio core sent the interrupt when it finishes
> playing the music
> > to processor.
> > -in the device driver code:
> >         -write() function blocks at rtems_semaphore_obtain(x) after
> > sending all data to hardware
> >         -an interrupt service routine will call
> rtems_semaphore_release(x)
> > which will wake up the write() to finish
> >
> > Is this scheme ok? Or RTEMS guys are usually doing something else..
>
> It should be OK.  Some people also use event send/receive for
> interaction between ISRs and tasks.  The choice depends on what you
> are controlling and what works more naturally.
>
> Out of curiousity, how much code, data, and bss is your application
> taking?  I am curious how light/heavy your application is.
>
> How much memory is required for effective buffering?  Where are your
> sound source files stored?
>
> So many questions.. ;)
>
> > Thanks much,
> > Pattara
> >
> > --
> > Please avoid sending me Word or PowerPoint attachments.
> > See http://www.fsf.org/philosophy/no-word-attachments.html
> > ----------------------------------------------------------------------
> > Ott Pattara Kiatisevi                              T L W G
> > M.Sc. INFOTECH Student, Stuttgart, Germany      http://linux.thai.net/
> > ----------------------------------------------------------------------
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>




More information about the users mailing list