parportbook.tmpl

嵌入式系统设计与实例开发实验教材二源码 多线程应用程序设计 串行端口程序设计 AD接口实验 CAN总线通信实验 GPS通信实验 Linux内核移植与编译实验 IC卡读写实验 SD驱动使

     <filename>/dev/parport0</filename> shares the parallel port in
     the same way as any other device driver.  A user-land driver may
     be sharing the parallel port with in-kernel device drivers as
     well as other user-land drivers.
    </para>
   </sect2>

   <sect2>
    <title>Control: <function>ioctl</function></title>

    <para>
     Most of the control is done, naturally enough, via the
     <function>ioctl</function> call.  Using
     <function>ioctl</function>, the user-land driver can control both
     the <literal>ppdev</literal> driver in the kernel and the
     physical parallel port itself.  The <function>ioctl</function>
     call takes as parameters a file descriptor (the one returned from
     opening the device node), a command, and optionally (a pointer
     to) some data.
    </para>

    <variablelist>
     <varlistentry><term><constant>PPCLAIM</constant></term>
      <listitem>

       <para>
	Claims access to the port.  As a user-land device driver
	writer, you will need to do this before you are able to
	actually change the state of the parallel port in any way.
	Note that some operations only affect the
	<literal>ppdev</literal> driver and not the port, such as
	<constant>PPSETMODE</constant>; they can be performed while
	access to the port is not claimed.
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPEXCL</constant></term>
      <listitem>

       <para>
	Instructs the kernel driver to forbid any sharing of the port
	with other drivers, i.e. it requests exclusivity.  The
	<constant>PPEXCL</constant> command is only valid when the
	port is not already claimed for use, and it may mean that the
	next <constant>PPCLAIM</constant> <function>ioctl</function>
	will fail: some other driver may already have registered
	itself on that port.
       </para>

       <para>
	Most device drivers don't need exclusive access to the port.
	It's only provided in case it is really needed, for example
	for devices where access to the port is required for extensive
	periods of time (many seconds).
       </para>

       <para>
	Note that the <constant>PPEXCL</constant>
	<function>ioctl</function> doesn't actually claim the port
	there and then---action is deferred until the
	<constant>PPCLAIM</constant> <function>ioctl</function> is
	performed.
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPRELEASE</constant></term>
      <listitem>

       <para>
	Releases the port.  Releasing the port undoes the effect of
	claiming the port.  It allows other device drivers to talk to
	their devices (assuming that there are any).
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPYIELD</constant></term>
      <listitem>

       <para>
	Yields the port to another driver.  This
	<function>ioctl</function> is a kind of short-hand for
	releasing the port and immediately reclaiming it.  It gives
	other drivers a chance to talk to their devices, but
	afterwards claims the port back.  An example of using this
	would be in a user-land printer driver: once a few characters
	have been written we could give the port to another device
	driver for a while, but if we still have characters to send to
	the printer we would want the port back as soon as possible.
       </para>

       <para>
	It is important not to claim the parallel port for too long,
	as other device drivers will have no time to service their
	devices.  If your device does not allow for parallel port
	sharing at all, it is better to claim the parallel port
	exclusively (see <constant>PPEXCL</constant>).
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPNEGOT</constant></term>
      <listitem>

       <para>
	Performs IEEE 1284 negotiation into a particular mode.
	Briefly, negotiation is the method by which the host and the
	peripheral decide on a protocol to use when transferring data.
       </para>

       <para>
	An IEEE 1284 compliant device will start out in compatibility
	mode, and then the host can negotiate to another mode (such as
	ECP).
       </para>

       <para>
	The <function>ioctl</function> parameter should be a pointer
	to an <type>int</type>; values for this are in
	<filename>incluce/linux/parport.h</filename> and include:
       </para>

       <itemizedlist spacing=compact>
	<listitem><para>
	  <constant>IEEE1284_MODE_COMPAT</constant></para></listitem>
	<listitem><para>
	  <constant>IEEE1284_MODE_NIBBLE</constant></para></listitem>
	<listitem><para>
	  <constant>IEEE1284_MODE_BYTE</constant></para></listitem>
	<listitem><para>
	  <constant>IEEE1284_MODE_EPP</constant></para></listitem>
	<listitem><para>
	  <constant>IEEE1284_MODE_ECP</constant></para></listitem>
       </itemizedlist>

       <para>
	The <constant>PPNEGOT</constant> <function>ioctl</function>
	actually does two things: it performs the on-the-wire
	negotiation, and it sets the behaviour of subsequent
	<function>read</function>/<function>write</function> calls so
	that they use that mode (but see
	<constant>PPSETMODE</constant>).
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPSETMODE</constant></term>
      <listitem>

       <para>
	Sets which IEEE 1284 protocol to use for the
	<function>read</function> and <function>write</function>
	calls.
       </para>

       <para>
	The <function>ioctl</function> parameter should be a pointer
	to an <type>int</type>.
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPGETMODE</constant></term>
      <listitem>

       <para>
	Retrieves the current IEEE 1284 mode to use for
	<function>read</function> and <function>write</function>.
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPGETTIME</constant></term>
      <listitem>

       <para>
	Retrieves the time-out value.  The <function>read</function>
	and <function>write</function> calls will time out if the
	peripheral doesn't respond quickly enough.  The
	<constant>PPGETTIME</constant> <function>ioctl</function>
	retrieves the length of time that the peripheral is allowed to
	have before giving up.
       </para>

       <para>
	The <function>ioctl</function> parameter should be a pointer
	to a <structname>struct timeval</structname>.
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPSETTIME</constant></term>
      <listitem>

       <para>
	Sets the time-out.  The <function>ioctl</function> parameter
	should be a pointer to a <structname>struct
	timeval</structname>.
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPGETMODES</constant></term>
      <listitem>

       <para>
	Retrieves the capabilities of the hardware (i.e. the
	<structfield>modes</structfield> field of the
	<structname>parport</structname> structure).
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPSETFLAGS</constant></term>
      <listitem>

       <para>
	Sets flags on the <literal>ppdev</literal> device which can
	affect future I/O operations.  Available flags are:
       </para>

       <itemizedlist spacing=compact>
	<listitem><para>
	  <constant>PP_FASTWRITE</constant></para></listitem>
	<listitem><para>
	  <constant>PP_FASTREAD</constant></para></listitem>
	<listitem><para>
	  <constant>PP_W91284PIC</constant></para></listitem>
       </itemizedlist>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPWCONTROL</constant></term>
      <listitem>

       <para>
	Sets the control lines.  The <function>ioctl</function>
	parameter is a pointer to an <type>unsigned char</type>, the
	bitwise OR of the control line values in
	<filename>include/linux/parport.h</filename>.
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPRCONTROL</constant></term>
      <listitem>

       <para>
	Returns the last value written to the control register, in the
	form of an <type>unsigned char</type>: each bit corresponds to
	a control line (although some are unused).  The
	<function>ioctl</function> parameter should be a pointer to an
	<type>unsigned char</type>.
       </para>

       <para>
	This doesn't actually touch the hardware; the last value
	written is remembered in software.  This is because some
	parallel port hardware does not offer read access to the
	control register.
       </para>

       <para>
	The control lines bits are defined in
	<filename>include/linux/parport.h</filename>:
       </para>

       <itemizedlist spacing=compact>
	<listitem><para>
	  <constant>PARPORT_CONTROL_STROBE</constant></para></listitem>
	  <listitem><para>
	  <constant>PARPORT_CONTROL_AUTOFD</constant></para></listitem>
	  <listitem><para>
	  <constant>PARPORT_CONTROL_SELECT</constant></para></listitem>
	  <listitem><para>
	  <constant>PARPORT_CONTROL_INIT</constant></para></listitem>
       </itemizedlist>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPFCONTROL</constant></term>
      <listitem>

       <para>
	Frobs the control lines.  Since a common operation is to
	change one of the control signals while leaving the others
	alone, it would be quite inefficient for the user-land driver
	to have to use <constant>PPRCONTROL</constant>, make the
	change, and then use <constant>PPWCONTROL</constant>.  Of
	course, each driver could remember what state the control
	lines are supposed to be in (they are never changed by
	anything else), but in order to provide
	<constant>PPRCONTROL</constant>, <literal>ppdev</literal>
	must remember the state of the control lines anyway.
       </para>

       <para>
	The <constant>PPFCONTROL</constant> <function>ioctl</function>
	is for <quote>frobbing</quote> control lines, and is like
	<constant>PPWCONTROL</constant> but acts on a restricted set
	of control lines.  The <function>ioctl</function> parameter is
	a pointer to a <structname>struct
	ppdev_frob_struct</structname>:
       </para>

       <programlisting>
	<![CDATA[
struct ppdev_frob_struct {
        unsigned char mask;
        unsigned char val;
};
	]]>
       </programlisting>

       <para>
	The <structfield>mask</structfield> and
	<structfield>val</structfield> fields are bitwise ORs of
	control line names (such as in
	<constant>PPWCONTROL</constant>).  The operation performed by
	<constant>PPFCONTROL</constant> is:
       </para>

       <programlisting>
	<![CDATA[
	new_ctr = (old_ctr & ~mask) | val;]]>
       </programlisting>

       <para>
	In other words, the signals named in
	<structfield>mask</structfield> are set to the values in
	<structfield>val</structfield>.
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPRSTATUS</constant></term>
      <listitem>

       <para>
	Returns an <type>unsigned char</type> containing bits set for
	each status line that is set (for instance,
	<constant>PARPORT_STATUS_BUSY</constant>).  The
	<function>ioctl</function> parameter should be a pointer to an
	<type>unsigned char</type>.
       </para>

      </listitem></varlistentry>

     <varlistentry><term><constant>PPDATADIR</constant></term>
      <listitem>

       <para>
	Controls the data line drivers.  Normally the computer's
	parallel port will drive the data lines, but for byte-wide
	transfers from the peripheral to the host it is useful to turn
	off those drivers and let the peripheral drive the
	signals. (If the drivers on the computer's parallel port are
	left on when this happens, the port might be damaged.)
       </para>

       <para>
	This is only needed in conjunction with
	<constant>PPWDATA</constant> or
	<constant>PPRDATA</constant>.
       </para>

       <para>
	The <function>ioctl</function> parameter is a pointer to an
	<type>int</type>.  If the <type>int</type> is zero, the
	drivers are turned on (forward direction); if non-zero, the
	drivers are turned off (reverse