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: http://www.aten-usa.com/download/drivers/as2p161w.exe)
> 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);
Tim.
*/
-- 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 : Thu Apr 06 2000 - 11:05:41 EDT