1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >How to Write a Driver</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos Reference Manual"
20 HREF="ecos-ref.html"><LINK
22 TITLE="I/O Package (Device Drivers)"
26 HREF="io-tty-driver.html"><LINK
28 TITLE="Serial testing with ser_filter"
29 HREF="io-serial-testing-with-serfilter.html"></HEAD
40 SUMMARY="Header navigation table"
49 >eCos Reference Manual</TH
57 HREF="io-tty-driver.html"
71 HREF="io-serial-testing-with-serfilter.html"
84 NAME="IO-HOW-TO-WRITE-A-DRIVER">Chapter 17. How to Write a Driver</H1
94 HREF="io-how-to-write-a-driver.html#IO-HOW-TO-WRITE-SERIAL-INTERFACE-DRIVER"
95 >How to Write a Serial Hardware Interface Driver</A
99 HREF="io-serial-testing-with-serfilter.html"
100 >Serial testing with ser_filter</A
105 >A device driver is nothing more than a
106 named entity that supports the basic I/O functions - read, write, get
107 config, and set config. Typically a device driver also uses and
108 manages interrupts from the device. While the interface is generic and
109 device driver independent, the actual driver implementation is
110 completely up to the device driver designer. </P
112 >That said, the reason for using a device driver is to provide
113 access to a device from application code in as general purpose a
114 fashion as reasonable. Most driver writers are also concerned with
115 making this access as simple as possible while being as efficient
118 >Most device drivers are concerned with the movement of information,
119 for example data bytes along a serial interface, or packets in a
120 network. In order to make the most efficient use of system resources,
121 interrupts are used. This will allow other application processing
122 to take place while the data transfers are under way, with interrupts
123 used to indicate when various events have occurred. For example,
124 a serial port typically generates an interrupt after a character
125 has been sent “down the wire” and the interface
126 is ready for another. It makes sense to allow further application
127 processing while the data is being sent since this can take quite
128 a long time. The interrupt can be used to allow the driver to send
129 a character as soon as the current one is complete, without any
130 active participation by the application code. </P
132 >The main building blocks for device drivers are found in the
135 ><cyg/io/devtab.h></TT
138 >All device drivers in <SPAN
145 by a device table entry, using the <SPAN
147 >cyg_devtab_entry_t</SPAN
149 The entry should be created using the <TT
161 CLASS="PROGRAMLISTING"
165 >(l, name, dep_name, handlers, init, lookup, priv)</PRE
187 >The "C" label for this device table entry.</P
198 >The "C" string name for the device.</P
209 >For a layered device, the "C" string name of the
210 device this device is built upon.</P
221 >A pointer to the I/O function "handlers" (see below).</P
232 >A function called when eCos is initialized. This
233 function can query the device, setup hardware, etc.</P
244 >A function called when <TT
259 >A placeholder for any device specific data
260 required by the driver.</P
265 >The interface to the driver is through the <TT
270 > field. This is a pointer to
271 a set of functions which implement the various <TT
275 routines. This table is defined by the macro:</P
283 CLASS="PROGRAMLISTING"
284 >DEVIO_TABLE(l, write, read, get_config, set_config)</PRE
306 >The "C" label for this table of handlers.</P
312 >The function called as a result of
322 >The function called as a result of
332 >The function called as a result of
335 >cyg_io_get_config()</TT
342 >The function called as a result of
345 >cyg_io_set_config()</TT
357 > is initialized (sometimes called
358 “boot” time), the <TT
362 for all devices in the system. The <TT
366 allowed to return an error in which case the device will be placed
367 “off line” and all I/O requests to that device will be
368 considered in error.</P
373 > function is called whenever
378 is called with this device name. The lookup function may cause the device
379 to come “on line” which would then allow I/O
380 operations to proceed. Future versions of the I/O system
381 will allow for other states, including power saving modes,
388 NAME="IO-HOW-TO-WRITE-SERIAL-INTERFACE-DRIVER">How to Write a Serial Hardware Interface Driver</H1
390 >The standard serial driver supplied with
397 > is structured as a hardware independent
398 portion and a hardware dependent interface module. To add support for
399 a new serial port, the user should be able to use the existing
400 hardware independent portion and just add their own interface driver which handles the details of the
401 actual device. The user should have no need to change the hardware
402 independent portion. </P
404 >The interfaces used by the serial driver and serial implementation
405 modules are contained in the file <TT
407 ><cyg/io/serial.h></TT
416 >In the sections below we use the notation <<xx>> to
417 mean a module specific value, referred to as “xx” below.</P
425 NAME="AEN10881">DevTab Entry</H2
427 >The interface module contains the devtab entry (or entries
428 if a single module supports more than one interface). This entry
429 should have the form: </P
437 CLASS="PROGRAMLISTING"
438 >DEVTAB_ENTRY(<<module_name>>,
439 <<device_name>>,
442 <<module_init>>,
443 <<module_lookup>>,
444 &<<serial_channel>>
467 >The "C" label for this devtab entry</P
478 >The "C" string for the
493 >The table of I/O functions. This set is defined in
494 the hardware independent serial driver and should be used.</P
505 >The module initialization function.</P
516 >The device lookup function. This function
517 typically sets up the device for actual use, turning on
518 interrupts, configuring the port, etc.</P
529 >This table (defined below) contains the interface
530 between the interface module and the serial driver proper.</P
540 NAME="AEN10918">Serial Channel Structure</H2
542 >Each serial device must have a “serial channel”.
543 This is a set of data which describes all operations on the device.
544 It also contains buffers, etc., if the device is to be buffered.
545 The serial channel is created by the macro: </P
553 CLASS="PROGRAMLISTING"
554 >SERIAL_CHANNEL_USING_INTERRUPTS(l, funs, dev_priv, baud,stop, parity, word_length,
555 flags, out_buf, out_buflen, in_buf, in_buflen)</PRE
577 >The "C" label for this structure.</P
588 >The set of interface functions (see below).</P
599 >A placeholder for any device specific data for
611 >The initial baud rate value
614 >cyg_serial_baud_t</SPAN
626 >The initial stop bits value
629 >cyg_serial_stop_bits_t</SPAN
641 >The initial parity mode value
644 >cyg_serial_parity_t</SPAN
656 >The initial word length value
659 >cyg_serial_word_length_t</SPAN
671 >The initial driver flags value.</P
682 >Pointer to the output
686 > if none required.</P
697 >The length of the output buffer.</P
708 >pointer to the input
712 > if none required.</P
723 >The length of the input buffer. </P
728 >If either buffer length is zero, no buffering will take place
729 in that direction and only polled mode functions will be used.</P
731 >The interface from the hardware independent driver into the
732 hardware interface module is contained in the <TT
738 This is defined by the macro:</P
745 NAME="AEN10993">Serial Functions Structure</H2
753 CLASS="PROGRAMLISTING"
754 >SERIAL_FUNS(l, putc, getc, set_config, start_xmit, stop_xmit)</PRE
776 >The "C" label for this structure.</P
789 >bool (*putc)(serial_channel *priv, unsigned char
793 > This function sends one character to the interface. It should
797 > if the character is actually consumed. It should
801 > if there is no space in the interface
815 >unsigned char (*getc)(serial_channel *priv)</TT
818 > This function fetches one character from the interface. It will
819 be only called in a non-interrupt driven mode, thus it should
820 wait for a character by polling the device until ready.
834 >bool (*set_config)(serial_channel
835 *priv,cyg_serial_info_t *config)</TT
838 > This function is used to configure the port. It should return
842 > if the hardware is updated to match the desired
843 configuration. It should return <TT
847 support some parameter specified by the given
848 configuration. E.g. selecting 1.5 stop bits and 8 data bits is
849 invalid for most serial devices and should not be allowed.
863 >void (*start_xmit)(serial_channel *priv)</TT
866 > In interrupt mode, turn on the transmitter and allow for
881 >void (*stop_xmit)(serial_channel *priv)</TT
884 >In interrupt mode, turn off the transmitter.</P
894 NAME="AEN11042">Callbacks</H2
896 >The device interface module can execute functions in the
897 hardware independent driver via <TT
899 >chan->callbacks</TT
901 These functions are available:</P
909 CLASS="PROGRAMLISTING"
910 >void (*serial_init)( serial_channel *chan )</PRE
915 >This function is used to initialize the serial channel. It
916 is only required if the channel is being used in interrupt
925 CLASS="PROGRAMLISTING"
926 >void (*xmt_char)( serial_channel *chan )</PRE
931 >This function would be called from an interrupt handler after a
932 transmit interrupt indicating that additional characters may be
933 sent. The upper driver will call the <TT
937 function as appropriate to send more data to the device.</P
945 CLASS="PROGRAMLISTING"
946 >void (*rcv_char)( serial_channel *chan, unsigned char c )</PRE
951 >This function is used to tell the driver that a character has arrived
952 at the interface. This function is typically called from the interrupt
955 >Furthermore, if the device has a FIFO it should require the hardware
956 independent driver to provide block transfer functionality (driver CDL
957 should include "implements
958 CYGINT_IO_SERIAL_BLOCK_TRANSFER"). In that case, the following
959 functions are available as well:</P
967 CLASS="PROGRAMLISTING"
968 >bool (*data_xmt_req)(serial_channel *chan,
971 unsigned char** chars)
972 void (*data_xmt_done)(serial_channel *chan)</PRE
977 >Instead of calling <TT
981 character for transmission at a time, the driver should call
985 > in a loop, requesting character
986 blocks for transfer. Call with a <TT
991 > argument of how much space
992 there is available in the FIFO.</P
994 >If the call returns <TT
997 >, the driver can read
1009 > and copy them into the FIFO.</P
1011 >If the call returns <TT
1015 no more buffered characters and the driver should continue without
1016 filling up the FIFO.</P
1018 >When all data has been unloaded, the
1019 driver must call <TT
1021 >data_xmt_done()</TT
1030 CLASS="PROGRAMLISTING"
1031 >bool (*data_rcv_req)(serial_channel *chan,
1034 unsigned char** space)
1035 void (*data_rcv_done)(serial_channel *chan)</PRE
1040 >Instead of calling <TT
1044 character at a time, the driver should call
1048 > in a loop, requesting space to
1049 unload the FIFO to. <TT
1055 characters the driver wishes to unload.</P
1057 >If the call returns <TT
1060 >, the driver can copy
1074 >If the call returns <TT
1077 >, the input buffer is
1078 full. It is up to the driver to decide what to do in that case
1079 (callback functions for registering overflow are being planned for
1080 later versions of the serial driver).</P
1082 >When all data has been unloaded, the driver must call
1085 >data_rcv_done()</TT
1095 SUMMARY="Footer navigation table"
1106 HREF="io-tty-driver.html"
1115 HREF="ecos-ref.html"
1124 HREF="io-serial-testing-with-serfilter.html"
1148 >Serial testing with ser_filter</TD