On Sun, Jul 02, 2000 at 05:13:28PM -0400, rjh@world.std.com wrote:
> 1) This assumes that the stop, turn around is fast enough to avoid a few
> extra bytes getting into the FIFO. (The code checks for this and
> reports an error when it happens.)
Yes. I wonder if it works to stop it before reading from the FIFO,
and then resume if we need more. That would close that race wouldn't
it?
> 2) It assumes that the peripheral is not perturbed by the host doing the
> port turn-around before all the bytes are read.
It assumes the peripheral is IEEE 1284 compliant, yes. There are lots
of places where it could probably be more forgiving.
> There must be a real motivation for this. I would not expect so much
> code without a reason. (I've ignored some of the interrupt event
> waiting from this since it does not seem critical to the logic. It is
> just an optimization to avoid busy waits checking FIFO status bits.
> Maybe this is where I missed something.)
While writing the code I imagined a peripheral with lots of data to
send, so I didn't want to use the FIFO (which can get filled up
quickly) if that would cause data loss. So if the client only wants a
few bytes, the idea is that we do it in software mode to prevent
losing any data.
Bear in mind that while writing it I didn't even have any proper
hardware to test with, just the spec.
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 : Mon Jul 03 2000 - 06:31:19 EDT