Daniel E. Ungar (dan@pgt.com)
Mon, 19 Oct 1998 12:19:24 -0400
Thomas Sailer wrote:
> BTW: It seems that although the ECP protocol could do it, in most
> implementations the host cannot force a direction change
> from backward to forward without possible data loss.
> How did you solve this problem? Just avoid it?
and David Campbell replied:
> Crowbar method (ugly but it works from experience)
> =======================================
> Place the ECP into FIFO test mode by writing 0xc0 to the ECR
> [base+0x402], this stops any further reads or writes to the FIFO. Empty
the
> FIFO by reading the ECP data register [base+0x400] while watching bit 0 of
> the ECR register (FIFO empty bit). When the FIFO is empty, set bit 4
(0x20)
> of the parallel port control register (base+2) low, this sets the data
direction
> to write. Now write 0x60 to the ECR (ECP FIFO mode).
Thank you for that advice, David. I wish we had consulted with you
three years back. At that time, we bought a third-party SBus card
[name withheld to protect the less-than-competent]. After
debugging their driver ourselves, we still hadn't figured out how
to exit ECP reverse mode without loosing the FIFO and input
register contents, so we jiggered our hardware to retransmit
those 17 bytes. Yucch!
I haven't gone over this with a fine-toothed comb, but to exit
ECP reverse phase without data loss, I think that the following
might also work to avoid data loss, if the peripheral hardware
behaves correctly.
First, negate nReverseRequest. This will stop the peripheral
from sending data up to the host and into the parallel port's
input register and FIFO. Then, read up to another 17 bytes
from the FIFO (including the byte from the input register).
Then, finally, exit ECP mode.
I'm sort of talking through my hat at this point. I really need
to sit down and read the chip documentation to understand
how all this interacts with ECP Rev2Fwd and Termination
phase handshake protocol and DMA counts.
BTW, for the intel i82091AA chip we were using, the data
book states that "If the parallel port is not in mode 000 or 001,
the port can only be switched into mode 000 or 001." So,
for that chip, we could *not* switch to Test mode (110) to
drain the FIFO. I think we had considered that method,
initially, but ruled it out for this reason.
Dan Ungar
dan@pgt.com
-- 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:38 EST