RTEMS device driver and interrupt

Angelo Fraietta angelo_f at bigpond.com
Fri Apr 12 00:50:48 UTC 2002

If you are using actual sound, the normal approach is to use DMA due to 
the large number of bytes to transmit. The CPU stops while the DMA is 
happening and you don't get the overhead involved with using an ISR 
(except when the transfer has completed)

Joel Sherrill wrote:

>Pattara Kiatisevi wrote:
>>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,
>>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/

Angelo Fraietta

PO Box 859
Hamilton NSW 2303

Home Page


There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
    Bernard of Clairvaux (1090 - 1153)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20020412/4d3bdfbd/attachment-0001.html>

More information about the users mailing list