[PARPORT] newbie questions

From: Peter Keller (psilord@cs.wisc.edu)
Date: Tue Oct 10 2000 - 00:32:17 EDT

  • Next message: Jan Vicherek: "[PARPORT] parallel port scanner HP5100C, linux2.2.14, - how ?"

    Hello,

    My name is Peter Keller, and I have joined this list because I have come
    to the end of my wits and I need outside help to get the information I
    need. The information that I seek does not appear to be in the archives
    (but they were helpful), nor documented anywhere that I can see. So,
    here I am.

    So, I might as well get on with it. :)

    I am using the parport device drivers (ppdev) on a linux 2.4.0-test8 kernel.
    I have set the bios on the machine to enable EPP mode. The bios is old
    and doen't have the EPP+ECP mode that newer bioses have. I only desire
    EPP mode anyway.

    Now, I built a very simple breakout box that showed that I could correctly
    write to the parallel port in standard mode. I could read from the status
    pins and mess with the control lines. This all apparently works and with
    ppdev too.

    Then, I built a piece of hardware that spoke EPP. It doesn't work. :)
    My question comes in the form of how do I read and write ADDRESS versus DATA
    contexts?

    In the book that I have:
    Programming the Parallel Port: Interfaceing the PC for Data Acquisition and
    Process Control, Gadre, Dhanajay

    It states that there are address strobes and data strobes that can be written
    or read from by coercing a BASE_ADDRESS + MAGIC_OFFSET the correspondes for
    each type of read/write, address, or data. The book goes on to show timing
    diagrams that states which signals do what, and for what context.

    However, I looked through ppdev.h and noticed that there isn't a clearly
    defined interface for me to tell the parport to read/write an address cycle
    or a data cycle. There is in parport.h, but it looks like I need to be in
    a kernel driver to use it correctly. Is that the case?

    This is causing me no end of headaches as I don't know what to make of it.

    For instance, when I do this:
    (grabbed from another message by Derek Bouius)

    int mode2 = IEEE1284_MODE_EPP;
    fd = open ("/dev/parport0", O_RDWR | O_NOCTTY);
    ret = ioctl (fd, PPCLAIM);
    ret = ioctl (fd, PPNEGOT, &mode2); //negotiates to EPP
    ret = ioctl (fd, PPSETMODE, &mode2); // sets the driver states
    ch=0x57;
    num=1;
    ret = write (fd, &ch, num); // writes out 0x57 on the port in EPP mode

    In what context is the data being written out? Data or Address? Also,
    what happens if I don't perform the PPNEGOT? Doesn't the PPSETMODE take
    care of the fact that I wanted EPP mode? Is the PPNEGOT a specific thing
    for a certain type of printer or some such hardware?

    The data appears on the bus, and then the write blocks forever. Now it could
    be that I have miswired my NWAIT signal, and I have to inspect it again for
    the fourth time to make sure. :)

    Also, what does PPDATADIR do? I set it to output mode when I write, and
    input mode when I read, but only because it seems sensical to do so.

    The hardare I've built needs to know the difference between an address
    read/write and a data read/write(I've sortof built a small microcontroller
    that I need to feed instructions, and then get the data from it). How do
    I do these in ppdev? Also, how can I tell if my parport is even working
    at all in EPP mode? The ioctls might have returned success, but how do
    I _really_ know?

    I'm sorry for the rapid fire of questions, but ppdev looks very cool, and
    I seem to be hampered merely by a lack of documentation. :) The archive
    was very helpful to getting me as far as I've got and I appreciate the
    imformation in it.

    I can make all of my code available of need be, it is GPL'ed.

    Thank you.

    -pete

    -- To unsubscribe, send mail to: linux-parport-request@torque.net --
    -- with the single word "unsubscribe" in the body of the message. --



    This archive was generated by hypermail 2b29 : Fri Oct 13 2000 - 02:37:46 EDT