Nicolas Souchu (firstname.lastname@example.org)
Wed, 9 Dec 1998 00:22:38 +0000
On Tue, Dec 08, 1998 at 07:37:39PM +0000, Tim Waugh wrote:
>> At least in my application it doesn't make sense
>> to use ECP when the hardware doesn't directly support it.
>The only reason it would be necessary is if the peripheral ONLY speak ECP
>mode, and we don't have the hardware for it.
Then, the peripheral is not IEEE1284 compliant. But,
- peripheral behaviour may be easier to analyze with emulation
(OfficeJet development is an example)
- when 2 hosts exchange data, one of them, with full ECP support,
may want to take advantage of DMA+hardware_handshake
- just for fun
BTW, Tim, did you think about host<->host operations? The main issue is
reverting the negociation with only 4 control lines against 5 status lines.
I talk to you about this in order to get FreeBSD<->Linux _compatible_ for
an ECP/EPP-IP interface. A nice challenge... just with IEEE1284 specifications.
I'm about to install a Linux box to get the old-style lp/plip Linux stuff
work with our new ppbus interface.
Here is the cable I propose for this:
nStrobe <-> nAck 1 <-> 10
nAutofd <-> Busy 11 <-> 14
nSelectin <-> Select 17 <-> 13
nInit <-> nFault 15 <-> 16
* 1/10 and 11/14 are mandatory for ECP handshake.
* 17 and 13 are identical during BYTE and ECP transfers.
* 16 is mandatory, then 15 is connected to it. This is compatible with
the ECP nPeriphRequest interrupt scheme: while forwarding, nInit is high
(nFault is high).
Finally, PERROR is mostly identical to SELECT, so PERROR is ignored.
And if I'm not wrong, that's ok with EPP mode.
It forces us to insert few strobes in the negociation protocol to hint the
remote host. It shouldn't disturb existing peripherals if other lines are
well choosen. I'm currently testing it with my printer.
-- email@example.com / firstname.lastname@example.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:52 EST