[PARPORT] EPP Problems?


WODECKI, Victor (VWODECKI@baea.com.au)
Thu, 13 Jan 2000 16:10:43 +1030


As I mentioned a while ago on this list, I'm trying to talk to a DSP
device via a parallel interface, using Linux. My development machine is
a dual-boot machine, with 2.2.13 (with the ppdev patch) and Windows95.
(And an "IEEE-1284 Parallel Printer Cable".)

The manufacturer of the DSP hardware (Analog Devices) supplies a
Windows95 binary, which lets the user play with the hardware. This
software works under Windows95 on this machine, but I am having
troubles writing software under Linux to talk to the device.

On this machine, the W95 software works only when the BIOS is set to EPP
(as opposed to ECP, or ECP+EPP, or NORMAL). The documentation for the
hardware states that "The PC printer port must be IEEE-1284 compatible
in the standard bidirectional mode", but not much else of interest.

Under Linux (RH6.1 with 2.2.13 plus ppdev patch), when I do a insmod
parport_probe, I get "parport0: no IEEE-1284 device present.". When I
run deviceid-0.1 on /dev/parport0, I get
"deviceid: device not IEEE 1284 compliant".

In my own test program, I perform the following sequence;
  fd = open ("/dev/parport0", O_RDWR | O_NOCTTY)
  ioctl (fd, PPCLAIM)
  mode = IEEE1284_MODE_EPP | IEEE1284_ADDR
  ioctl (fd, PPNEGOT, &mode)
This fails on the PPNEGOT, with EIO. Poking about with tracewrites in
ppdev.c seems to show that it fails in negotiate(), waiting for nAck to
go low.

If I insert, before the failing ioctl, the following
  mode = IEEE1284_MODE_EPP
  ioctl (fd, PPSETMODE, &mode)
then the failing ioctrl (PPNEGOT) now succeeds, although ppdev then
seems to get stuck in a loop when I do the actual write() of the
address.

I've tried to find out what the W95 app does by using PortMon, but that
doesn't see anything (their s/w probably hits the h/w directly), and
I've also tried it under Wine, but that gets nowhere, and vmware doesn't
work with EPP (only ECP?).

I'm not sure what to make of all this. Is ppdev what I should be
using? It seems to be the neatest approach, but it might not work for
this device. Do the above symptoms mean that the device is only
partially IEEE1284-compliant?

I did ask the manufacturer for more information on the interface, but
all they said was
  "We are compliant with the timing and configuration of IEEE 1284.
   This document is available from IEEE as well as much data available
   on the internet. I/O's are simple Inp and Outp 'C' commands are
   all that are needed."

All suggestions welcome.

-- 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 Thu 13 Jan 2000 - 00:50:52 EST