Tim Waugh (tim@cyberelk.demon.co.uk)
Tue, 8 Dec 1998 23:53:57 +0000 (GMT)
On Wed, 9 Dec 1998, Nicolas Souchu wrote:
> >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.
I meant for the reverse channel -- it might only speak compatibility mode
and ECP mode. Software-emulated ECP-write is only really justifiable with
your examples:
> 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
For some reason, the SPI in 1284-1994 says that the list of modes that
SPI_IO understands (for its 'mode' parameter) includes both ECP and
ECP-with-software-emulation. Weird.
> 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 hadn't, but the idea intrigues me. I'll have to draw myself some
pictures from your wiring scheme.
> I talk to you about this in order to get FreeBSD<->Linux _compatible_
> for an ECP/EPP-IP interface.
Excellent plan. I'm sorry to say that I haven't been following FreeBSD
development with ppbus. Thanks for the link, btw.
> Thoughts?
I'll get my thinking cap on.
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 2.0b3 on Wed 30 Dec 1998 - 10:18:52 EST