Re: [PARPORT] Re: Help using PPDEV with EPP

From: David Hawkins (
Date: Mon Aug 14 2000 - 12:20:21 EDT

  • Next message: Oversoul: "[PARPORT] parallel zip 250"

    Thanks for the helpful reply Tim.

    Its turns out that I hadn't typed 'make modules' after
    reconfiguring the kernel.(A lack of kernel re-compiling
    experience ...).

    I appreciate your comments below and I will look at
    them in more detail when I finish looking at the 1284 spec.

    One general observation while performing the tests was
    that the address writes and data writes were lighting up
    the same 7-segment display. Whereas, if I opened
    /dev/port and lseeked to the EPP address and data
    ports, writes via that method would correctly light
    up the appropriate address or data 7-segment display.
    (I assume this method would correspond to using the
    'hardware-accelerated functions' you mention below).

    FYI, I have an EPP state machine in an FPGA that
    is currently configured just to latch EPP address and
    data write cycles, which then lights a couple of 7-segment
    displays that show the address or data LSB, and provides
    the byte address or data for readback. I use this FSM as
    the interface to control additional hardware on prototype

    Thanks again for your help Tim. No need to reply
    to these comments. When I get a chance to look at this
    again over the weekend I'll see if I can repeat what I
    mentioned above, and then perhaps use the parport_pc
    functions directly to improve my understanding of the


    Dave Hawkins


    On Mon, Aug 07, 2000 at 07:28:57PM -0700, David Hawkins wrote:

    > 3. ran 'make config' and setup the parallel ports as loadable
    > modules - same for ppdev. Note: I also ran make xconfig to
    > do this, however, although ppdev showed up in the selection
    > menu, attempts to alter the check-box gave an error (visible
    > back in the xterm it was executed from). I recompiled the
    > kernel, updated the slocate database and ran 'slocate ppdev'.
    > Although there were some new ppdev directories generated
    > during the make process, I didn't get a ppdev.o file
    > generated. Any comments on this?

    Did you do 'make modules'? slocate won't show you anything that's
    been created since the last updatedb: did you look for ppdev.o in the
    right place (drivers/char)?

    > 6. I then ran variations on the code below and have the
    > following observations/suggestions:
    > - the call to PPNEGOT fails. I didn't delve too far into the
    > source code for this call, but does this call require a response
    > the 1284 device? If it does, what are the address/data cycles -
    > I can easily implement the appropriate response in my device.

    It performs IEEE 1284 negotiation. If your device doesn't do that,
    just don't bother with PPNEGOT.

    > - both writes appear to go to the address port, (using PPSETMODE to
    > select the data port didn't seem to work).

    All PPSETMODE does it tell the ppdev driver which IEEE 1284 mode
    should be used for read() and write().

    > I looked at the source code to see what the function calling
    > sequence looks like and get:
    > User space read/write are implemented via pp_read / pp_write,
    > which are implemented via parport_read / parport_write
    > in which a switch statement selects from the four functions
    > ieee1284_epp_[read/write]_[addr/data].

    If the lowlevel driver (parport_pc in your case) provides
    hardware-accelerated functions for those transfers then they are used

    In parport_pc port->ops gets set to use ieee1284_xxx by default; the
    hardware detection routines sometimes override them.

    > So why the added complexity in the implementations of the
    > ieee1284_epp_[read/write]_[addr/data] functions and why does it
    > look like the calls resolve to SPP reads/writes instead of EPP
    > or data reads/writes?

    EPP transfers can be done without EPP hardware; if the hardware is
    there it can be used, otherwise you have to use SPP registers.

    > There is a note at the top of these functions mentioning they are
    > untested.
    > If someone can give me the rational behind their implementation,
    > I will happily provide 'testing' of these functions in my

    The ieee1284_xxx routines? They just do the EPP handshaking. Note
    the difference between the EPP on-the-wire protocol and the chipset
    hardware that does it. Take a look at IEEE 1284.

    > In the ParPort docs, it is not clear what the difference between
    > read()
    > write() calls and ioctls with PPRDATA and PPWDATA.

    PPRDATA and PPWDATA deal with the current state of the data pins.
    Nothing more.

    read()/write() perform IEEE 1284 data/address transfers.

    > Looking at
    > the source code, I see that the ioctls resolve to parport_write_data
    > and parport_read_data, which as mentioned above resolve to SPP
    > read/writes in parport_pc.h. Would it be more appropriate for these
    > calls to mimic pp_read and pp_write?

    Not at all: pp_read and pp_write are for doing IEEE 1284 data/address
    transfers, whereas parport_read_data/parport_write_data ===


    -- To unsubscribe, send mail to: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Mon Aug 14 2000 - 12:26:43 EDT