[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Device Driver Skeleton?

Angelo Fraietta wrote:

angelo wrote:

On Fri Feb 11 10:00:51 PST 2005, =?iso-8859-1?Q?Alex?= <kbyte@iol.pt> wrote:

Good Morning Dr Fraietta,

Not Dr yet.

At some days ago, I had a doubt concerning writing my first device driver and you said to me to send you an email on the 10th feb. So here I am... Could you help me, please?


I already study the console and serial drivers in the rtems distribution and appart from the skeletton of a generic rtems device driver, why do we have to define always a macro like this:

  { console_initialize, console_open, console_close, \
    console_read, console_write, console_control }

So the application which builds the device driver table doesn't have
to know the details of a particular driver. Maybe you have a write only console and don't support read. This is really an application configuration convenience.

Who invoke those functions members, and in what circunstancies?

This is my understanding of what happens. Hopefully, someone will correct me if I am wrong.
The initisalise function,

console_initialize in this case, is called when the device drivers are initialised.
The Open is when you a file open on this device, the close when you do a file close, the read when do do a read from the file, the write, when you do a write to the file, and I am not sure what the control does.

Correct. device driver initialization in this case is done before multtaskign is started. Do not block in a driver initialization of you will hang the system.

I have only implemented the initialise because I write to my device direct. I have not implemented a read, or write -- I don't treat my device like a file. I suppose that that is what you have to decide first--whether you want to treat your device like a file or whether you want to write directly from your application

Correct. The other calls help plug into the filesystem framework and let you access /dev/console or /dev/comm0 or /dev/hd0 just like you would be able to on a POSIX system.

Which are the steps to put to work a device driver made by us, or, using the hello world sample how can we put a device driver to work?

I would have a look at an example that uses a COMM port (TTYS1) if you want to open and close your device like a file.

Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985