Dale Whitfield (dale@elad.cix.co.uk)
Sun, 21 Mar 1999 15:01:42 +0000
>So, to get this straight, your device talks ECP mode on the wire, but
>using the IEEE1284 features of the hardware to talk ECP with it won't
>work? Have I understood you?
Partly. The device uses _both_ hardware and software modes.
I'll try and give the scenario:
There is a device, which the driver communicates with using ECP-mode. The
device has a slow EEPROM attached to it. It is possible for the driver to use
the device to write data to the EEPROM. The link to the EEPROM is serial and
slow.
Now, most communication which results in data for the device only can be done
in hardware (true ECP) mode. Others, which target the EEPROM, must be done
using ECP-emulated PS/2 mode with handshaking emulated in software. The only
difference is timing. This allows, for example, time for the data lines to
settle during the handshake cycle.
>You haven't shown me a datasheet that says it is possible to read an
>address byte in ECP mode by getting the hardware to do the handshaking.
>You said WinBond -- I looked up the datasheet and it said no such thing,
>as far as I could tell. Yes, you can read from ecpAFifo, but there's no
>guarantee of its contents (it explicitly says that later on). That's just
>another way of saying that it's write-only.
The spec sheet I have here (WinBond W83877F) talks about Command/Data in both
directions, but...
You miss the point. You don't know if a manufacturer is making one as we speak.
Its not a case of catering for chips you know about but allowing for
functionality that is specified.
>Dale, how does the QuickCam know if software or hardware is driving the
>timing of the signals on the wire?
It doesn't know if its hardware or software but the timing is what makes the
difference.
Dale.
-- 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 Sun 28 Mar 1999 - 17:05:30 EST