Re: [PARPORT] simple driver

From: Tim Waugh (
Date: Thu Apr 06 2000 - 11:01:37 EDT

  • Next message: Nordic Boy: "Re: [PARPORT] simple driver"

    On Wed, 5 Apr 2000, Nordic Boy wrote:

    > To start at the beginning. I am trying to write a parallel port
    > driver for an electronic switch, specifically a printer switch,
    > although this could be applied to a bidirectional switch made by the
    > same company. I have an ATEN AS-152 switch. This is a dual mode
    > switch, which means that it can take two computers and attach them to
    > one printer or two printers and attach them to one computer. The DOS
    > and Windows drivers require manual intervention to cause the device to
    > switch ports when it is one computer attached to two printers (it is
    > automatic the other direction).

    There is a specification for this kind of thing (IEEE
    1284.3); unfortunately, ATEN seems to have ignored it. :-(

    If you take a look in 2.3.99-pre4-4 you'll see some code to deal with
    port multiplexors like this, using CPP protocol (see daisy.c). It's never
    been tested, because I've never seen one of these devices. ;-)

    I'd like to get hold of one of these ATEN boxes -- does anyone know where
    in the UK I'd be able to find one?

    > I have a copy of some dos example code (this was included in the
    > drivers here:
    > and I am attempting to write drivers for linux that would make the
    > switch operate essentially automatically (more on this later).

    (Incidentally, what's the license of the source code? The 'manual'
    doesn't give programming information out..)

    > After reading the module documentation and setting this up as a
    > module, I was able to get my driver to get a list of ports and attach
    > my driver and claim each of the ports (actually, I only have one on
    > the machine). I can see that parport is using my driver when looking
    > in proc so I am assuming that that I should be able to use the port at
    > will from this point.

    Great. You have to claim the port first (use parport_claim_or_block), but
    that's basically fine.

    > outp(port_adr+2 , inp(port_adr+2) & 0xf7) ;

    nSelectIn high:

    parport_frob_control (port, PARPORT_CONTROL_SELECT, 0);

    > outp(port_adr, code1); wait(); outp(port_adr, code1 |0x80); wait();
    > outp(port_adr, code2); wait(); outp(port_adr, code2 |0x80); wait();
    > outp(port_adr, code3); wait(); outp(port_adr, code3 |0x80); wait();

    This is writing stuff to the data lines, and qualifying it with bit 7: the
    peripheral knows to look at the data lines when bit 7 goes logic
    high. IEEE 1284.3 does a similar thing, but flips _all_ the bits to get
    the peripheral's attention.

    This is parport_write_data stuff.

    > outp(port_adr+2 , inp(port_adr+2) | 0x08) ;

    This sets nSelectIn low again.

    > mydevice[0]->port->ops->write_control(mydevice[0]->port, 0x04);
    > mydevice[0]->port->ops->write_control(mydevice[0]->port, 0x84);
    > mydevice[0]->port->ops->write_control(mydevice[0]->port, 0x05);
    > mydevice[0]->port->ops->write_control(mydevice[0]->port, 0x85);
    > mydevice[0]->port->ops->write_control(mydevice[0]->port, 0x07);
    > mydevice[0]->port->ops->write_control(mydevice[0]->port, 0x87);

    You want this before:

    parport_frob_control (port, PARPORT_CONTROL_SELECT, 0);

    and this after:

    parport_frob_control (port, PARPORT_CONTROL_SELECT, PARPORT_CONTROL_SELECT);


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

    This archive was generated by hypermail 2b29 : Thu Apr 06 2000 - 11:05:41 EDT