Yes, ieee1284ops tries. I missed that. But, I'll bet it has
intermittent problems. The issue is with the EPP mode timeout.
The peripheral must raise nWait within 10 usec of the CPU dropping nIOW.
The CPU must raise nWait within 10 usec of the peripheral raising nIOR.
Meeting these timeout requirements is what makes firmware
implementations hard. For typical peripheral microcontrollers it means:
1) that the microcontroller must be totally dedicated to the transfer,
and 2) the data transfer cannot start until it is absolutely certain
that data storage will be available.
The last two peripherals where I was involved with firmware
implementations could afford the first requirement. The micro was very
slow and stupid (500nsec per instruction) so there was no hope of using
interrupts to permit other operation during transfers. But the
transfers were small enough that users would not mind the peripheral
controls being locked during transfer. There was a problem with data.
It could not guarentee that data writes would complete within
10usec because it wrote directly to the hardware controls. To utilize
EPP would have forced full buffering of all data transfers from computer
to peripheral. ECP permits delays when necessary. Using ECP eliminated
the buffering requirement from the design.
I did not see in ieee1284ops where you disable interrupts. An EPP read
that gets hit by an interrupt at the wrong time probably misses that
10usec timeout. Now you are in the hands of the peripheral for whether
it cares or not. This makes simulated EPP reads unreliable.
ECP also has a few time limits, but they are measured in milliseconds.
There remains the bi-directional issue. ECP has a standard definition
for the process of switching directions. EPP has traditions, but no
official standard.
R Horn
-- 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 : Sat Apr 21 2001 - 16:44:33 EDT