RTEMS device driver and interrupt

[Pattara Kiatisevi]

Thank you for all answer. The setting is like this: we have the audio core
in the design which has registers like:

controlreg
startaddr
stopaddr
status

With a proper write to controlreg, audio core will start to do the DMA of
sound data from memory starting from startaddr to stopaddr. During the
sound play period, status will be at 1, otherwise 0.

And my task is to write a device driver for /dev/dsp. As I observed from
PC, writing to /dev/dsp will block until all music is played. So I try to
implement such thing with RTEMS. So the plan is to have the audiocore sent
an interrupt when all music is played. I'm experimenting with it now.

FIFO buffer in hardware? Hmm, interesting. Could I see this behaviour on
normal soundcards for PC?

NO_BLOCK write is also interesting, thank you.

[..]

> Let me rephrase the questions...
>
>   + if you are decoding Ogg files to a raw bit stream, how much
>     code space does the decoding take?  data space? work RAM? CPU time?

$ sparc-rtems-size  player-rtems-nofpu-softwareonly
   text    data     bss     dec     hex filename
 277760  258672   13980  550412   8660c player-rtems-nofpu-softwareonly

Ogg file = now in data segment. Future --> from network (or USB). To
write a ethernet device driver for RTEMS, do you recommend any place to
start from? And how about USB?

Work RAM. Hmm, I have observed on Linux PC, it was around 1.5 MB.

For CPU time, now we are trying our best to have the music played in
real-time. (hmm, does this answer the question?)

>   + what size buffers are you using to DMA?  Alternate version of
>     question.. when you get an interrupt saying "give me more data"
>     how much data do you give it?  How often does this happen?

This is actually configurable. The size we used was 4 kB. And as the music
was not yet real-time. The sound was un-understandable. So I changed it to
something big (600 kB). The time pause while DMA (@33 MHz =
600,000/4/(33e06)) --> 4.5 ms, hopefully not observable by audiophile (?).
Any better suggestion?

Thank you very much,
Pattara

 >
> I am generally trying to figure out how small an embedded system
> can be from a HW perspective and still do this.
>
> --joel
>
>
> > Joel Sherrill wrote:
> >
> > > 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/
> > >> ----------------------------------------------------------------------
> > >>
> >
> > --
> > Angelo Fraietta
> >
> > PO Box 859
> > Hamilton NSW 2303
> >
> > Home Page
> >
> > http://www.users.bigpond.com/angelo_f/
> >
> > 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)
>
> --
> 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
>
>