Device Driver Skeleton?

[Joel Sherrill <joel@OARcorp.com>]

Angelo Fraietta wrote:
> 
> 
> angelo wrote:
> 
>>
>>
>> On Fri Feb 11 10:00:51 PST 2005, =?iso-8859-1?Q?Alex?= <kbyte at 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?
>>>   
> 
> OK
> 
>>> 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:
>>>
>>>  #define CONSOLE_DRIVER_TABLE_ENTRY \
>>>   { 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 at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985