Quoting Juergen Voelkel <email@example.com>:
> my peripheral device supports only ecp, hence negotioation fails (or the
> device isn't 1284-compliant - don't know). is a successful negotiation
> necessary for a proper operation of ieee1284_ecp_read_data?
If it supports ECP, then negotiation shouldn't be failing, but yes it's assumed
that you have negotiated ECP if you wish to use ECP reads.
> if so, do I have to switch to ieee1284_ecp_fwd_to_rev before? it returns
> 'not implemented'. documentation speaks of possible limitations of this
> version (API 3).
fwd_to_rev is used to change direction once ECP has been negotiated.
Negotiation leaves the port in "forward" mode, which is the computer writing to
the peripheral. libieee1284 should remember the state of the port, so if you
attempt a read it will reverse the direction first.
> what is the difference between ECP and software implemented ECPSWE?
ECP can be implemented in hardware, where the parallel port chip understands
how to negotiate and change modes, and how to clock data in and out of the port
by twiddling the correct pins. This enables DMA or interrupt transfers to
occur, which leaves the CPU free to perform other tasks. ECPSWE is where
either ppdev or libieee1284 manually control all the pins on the port in order
to implement the negotiations, and manually clock every piece of data in and
out. This means that several instructions and port controls are required for
each byte, which is normally much slower.
There's also a list specifically for libieee1284 at:
- Matthew Duggan
This mail sent through IMP: http://horde.org/imp/
-- 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 : Fri Oct 25 2002 - 05:06:40 EDT