You're, of course, right about the end of block. With EPF the most
likely exception condition is out-of-paper. With the typical 4K block
and the typical 16 byte fifo that leaves about 0.4% chance that when
paper runs out it'll do so with at end of the block. Or that one in
every two hundred paper-outs may corrupt data on restart.
Forcing STROBE was described for true ECP mode in the MS doc. While I
haven't tried it for ECP mode (no test hardware) it didn't work for me
in EPF mode. The printer locked up like a Windows PC. I had to power off
to recover. Hence a new suggestion. I'll play some with the available
control signals (STROBE and SelectIn).
Another possible option is to leave the printer in EPF so that data from
the next block can be used to fill the fifo. The context state issues
and possible side effects of that are a nightmare.
Another nasty solution is to fill the fifo with nulls while in EPF mode
switching to PS2 mode immediately on the full condition. That'd have
only a few microseconds of risk. That's probably the true hardware
behaviour of the current code, the ECR_TST is treated as a nop by the
hardware. The chance that the error condition will clear (and data
transfer resume) after we start filling the fifo and but before we
change to PS2 mode has to be real, real small. One in a few hundred
thousand paper-outs I'd say.
The last solution I've thought about carries a performance penalty for
every block. Always leave the last 16 (fifo size) bytes unsent. So the
time-out logic can always force a fifo full condition. To be really
safe the last fifo worth of bytes in a stream would need to go via PS2
mode. Or even more generic for even more of a performance loss -- always
send the last bytes of a block PS2 mode. This strikes me as the classic
$100 solution to the 10 cent problem. But it is THE most reliable
solution I can think of (right now away).
-- To unsubscribe, send mail to: firstname.lastname@example.org --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Thu Dec 20 2001 - 15:17:59 EST