RTEMS sound device driver

[Joel Sherrill]

Pattara Kiatisevi wrote:
> 
> It works now! Thank you everybody.
> 
> Ok, next step I will be implementing this sound driver. Still I have more
> questions.  Do we have such things like these in RTEMS (or please point
> me to the manual)?
> 
> -printk() hmmm and how to see the log output? :)

Yes.  include <rtems/bspIo.h> and provide the hooks in your BSP.
The pc386 has these.

> -kmalloc()
> -copy_to_user()
> -copy_from_user()

RTEMS does not have memory protection so there is no need for separate
kernel malloc or copying to/from user space.  I would think that macros
to map these to malloc() and memcpy() would be the easiest thing to do.
Especially since you could provide them in an adapter layer to avoid
making more changes.
 
> Thank you,
> Pattara
> 
> The best things in life are free. - B.G. DeSilva (1927)
> ----------------------------------------------------------------------
> Ott Pattara Kiatisevi                              T L W G
> M.Sc. INFOTECH Student, Stuttgart, Germany      http://linux.thai.net/
> ----------------------------------------------------------------------
> 
> On Fri, 8 Feb 2002, Joel Sherrill wrote:
> 
> > Pattara Kiatisevi wrote:
> > >
> > > OK, meanwhile I am trying this static method as you suggested while
> > > waiting for the new dynamic one. (In the hope also to understand more
> > > about RTEMS)
> > >
> > > 1.I created sound.h in my local application directory containing:
> > >
> > > #define SOUND_DRIVER_TABLE_ENTRY \
> > >   { sound_initialize, sound_open, sound_close, \
> > >     sound_read, sound_write, sound_control }
> > > and the declarations of these 6 functions (copied from in console.h).
> > >
> > > 2.I created sound.c containing:
> > >
> > > rtems_device_driver sound_initialize(
> > >   rtems_device_major_number  major,
> > >   rtems_device_minor_number  minor,
> > >   void                      *arg
> > > )
> > > {
> > >   rtems_status_code status;
> > >
> > >   /*
> > >    *  Register Device Names
> > >    */
> > >
> > >   status = rtems_io_register_name( "/dev/dsp", major, 0 );
> > >   if (status != RTEMS_SUCCESSFUL)
> > >     rtems_fatal_error_occurred(status);
> > >
> > >   /*
> > >    *  Initialize Hardware
> > >    */
> > >
> > >   return RTEMS_SUCCESSFUL;
> > > }
> > >
> > > For the rest 5 functions, I just have "return RTEMS_SUCCESSFUL;" inside.
> > >
> > > 3.In my application header, I have such thing like this:
> > >
> > > [cut]
> > > #define CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
> > >
> > > #define CONFIGURE_MAXIMUM_DRIVERS 10
> >
> >
> > > #include <console.h>
> > > #include "sound.h"
> > >
> > > rtems_driver_address_table Device_drivers[] = {
> > >         CONSOLE_DRIVER_TABLE_ENTRY,
> > >         SOUND_DRIVER_TABLE_ENTRY,
> > >         { NULL, NULL, NULL, NULL, NULL, NULL }
> > > };
> > >
> > > #include <confdefs.h>
> > >
> > > [cut]
> > >
> > > #define open_mode 1
> > > #define DEVICE_NAME "/dev/dsp"
> > >
> > > [cut]
> > >   /* Open sound device */
> > >   if ( (audio_fd = open(DEVICE_NAME, open_mode, 0) ) == -1 ) {
> > >     /* open of a device failed */
> > >     perror(DEVICE_NAME);
> > >     exit(1);
> > >   }
> > >
> > > Then I compiled and ran the code and got this error:
> > >
> > > /dev/dsp: Too many open files in system
> > >
> > > Do you have any clues?
> >
> > The error message was actually right in this case. :)
> >
> > By default, RTEMS only provides 3 file descriptors (stdin, out,
> > and error).
> >
> > #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS XXX
> >
> > where XXX is some number greater than 3. :)
> >
> > > Thank you very much,
> > > Pattara
> > >
> > > On Thu, 7 Feb 2002, Aaron J. Grier wrote:
> > >
> > > > On Fri, Feb 08, 2002 at 12:02:33AM +0100, Pattara Kiatisevi wrote:
> > > >
> > > > > But how exactly is this "registering" process? I took a look at the
> > > > > existing driver code as suggested and draft the steps as follow.
> > > >
> > > > rtems_io_register_name binds a name in filesystem space to the device
> > > > driver.
> > > >
> > > > > -I create a file contained device driver's code: sound-driver.c
> > > > >     -Which should contain initialize(), open(), close(), read(),
> > > > > write(), and control(). Arguments of these functions = like in console.c?
> > > >
> > > > yes.
> > > >
> > > > >     -In the initialize() I would have sth. like:
> > > > >
> > > > >     rtems_io_register_name( "/dev/dsp", major, 0 );
> > > > >
> > > > > -In my application file, I do open(), ioctl(), write(), close() to
> > > > > /dev/dsp as usual.
> > > >
> > > > you understand correctly.
> > > >
> > > > > -And then how can I tell RTEMS to call this sound device driver when there
> > > > > is access to /dev/dsp?
> > > >
> > > > after registering the device with rtems_io_register_name, you can
> > > > perform standard operations like open(), close(), lseek(), dup(), etc.
> > > > on your file.  RTEMS handles the "mid level" between these calls and
> > > > your device driver calls.
> > > >
> > > > > Something to do with #def CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE and I
> > > > > have to create my own Device_drivers? (Hmm, but how and where? :) )
> > > >
> > > > look at c/src/lib/include/console.h.  you define a table entry, and the
> > > > extern declarations for your driver entry points, then somewhere in your
> > > > confdefs.h:
> > > >
> > > > #define CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
> > > >
> > > > #include <console.h>
> > > >
> > > > rtems_driver_address_table Device_drivers[] = {
> > > >         CONSOLE_DRIVER_TABLE_ENTRY,
> > > >         { NULL, NULL, NULL, NULL, NULL, NULL }
> > > > };
> > > >
> > > > getting everything glued in to autoconf/automake so that they will be
> > > > compiled and linked into your BSP is a whole other story.  :)  let us
> > > > know if you need help with that.
> > > >
> > > > --
> > > >   Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at frye.com
> > > >      "In a few thousand years people will be scratching their heads
> > > >        wondering how on earth the first computer was invented and
> > > >           bootstrapped without a prior computer to do it with."
> > > >                     --  Chris Malcolm, on comp.arch
> > > >
> > > >
> >
> > --
> > 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
> >
> >

-- 
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