Thanks for the helpful reply Tim.
Its turns out that I hadn't typed 'make modules' after
reconfiguring the kernel.(A lack of kernel re-compiling
experience ...).
I appreciate your comments below and I will look at
them in more detail when I finish looking at the 1284 spec.
One general observation while performing the tests was
that the address writes and data writes were lighting up
the same 7-segment display. Whereas, if I opened
/dev/port and lseeked to the EPP address and data
ports, writes via that method would correctly light
up the appropriate address or data 7-segment display.
(I assume this method would correspond to using the
'hardware-accelerated functions' you mention below).
FYI, I have an EPP state machine in an FPGA that
is currently configured just to latch EPP address and
data write cycles, which then lights a couple of 7-segment
displays that show the address or data LSB, and provides
the byte address or data for readback. I use this FSM as
the interface to control additional hardware on prototype
boards
Thanks again for your help Tim. No need to reply
to these comments. When I get a chance to look at this
again over the weekend I'll see if I can repeat what I
mentioned above, and then perhaps use the parport_pc
functions directly to improve my understanding of the
interface.
Regards,
Dave Hawkins
--------------
On Mon, Aug 07, 2000 at 07:28:57PM -0700, David Hawkins wrote:
> 3. ran 'make config' and setup the parallel ports as loadable
> modules - same for ppdev. Note: I also ran make xconfig to
> do this, however, although ppdev showed up in the selection
> menu, attempts to alter the check-box gave an error (visible
> back in the xterm it was executed from). I recompiled the
> kernel, updated the slocate database and ran 'slocate ppdev'.
> Although there were some new ppdev directories generated
> during the make process, I didn't get a ppdev.o file
> generated. Any comments on this?
Did you do 'make modules'? slocate won't show you anything that's
been created since the last updatedb: did you look for ppdev.o in the
right place (drivers/char)?
> 6. I then ran variations on the code below and have the
> following observations/suggestions:
>
> - the call to PPNEGOT fails. I didn't delve too far into the
> source code for this call, but does this call require a response
from
> the 1284 device? If it does, what are the address/data cycles -
> I can easily implement the appropriate response in my device.
It performs IEEE 1284 negotiation. If your device doesn't do that,
just don't bother with PPNEGOT.
> - both writes appear to go to the address port, (using PPSETMODE to
> select the data port didn't seem to work).
All PPSETMODE does it tell the ppdev driver which IEEE 1284 mode
should be used for read() and write().
> I looked at the source code to see what the function calling
> sequence looks like and get:
>
> User space read/write are implemented via pp_read / pp_write,
> which are implemented via parport_read / parport_write
> in which a switch statement selects from the four functions
> ieee1284_epp_[read/write]_[addr/data].
If the lowlevel driver (parport_pc in your case) provides
hardware-accelerated functions for those transfers then they are used
instead.
In parport_pc port->ops gets set to use ieee1284_xxx by default; the
hardware detection routines sometimes override them.
> So why the added complexity in the implementations of the
> ieee1284_epp_[read/write]_[addr/data] functions and why does it
> look like the calls resolve to SPP reads/writes instead of EPP
address
> or data reads/writes?
EPP transfers can be done without EPP hardware; if the hardware is
there it can be used, otherwise you have to use SPP registers.
> There is a note at the top of these functions mentioning they are
> untested.
> If someone can give me the rational behind their implementation,
> I will happily provide 'testing' of these functions in my
environment.
The ieee1284_xxx routines? They just do the EPP handshaking. Note
the difference between the EPP on-the-wire protocol and the chipset
hardware that does it. Take a look at IEEE 1284.
> In the ParPort docs, it is not clear what the difference between
> read()
> write() calls and ioctls with PPRDATA and PPWDATA.
PPRDATA and PPWDATA deal with the current state of the data pins.
Nothing more.
read()/write() perform IEEE 1284 data/address transfers.
> Looking at
> the source code, I see that the ioctls resolve to parport_write_data
> and parport_read_data, which as mentioned above resolve to SPP
> read/writes in parport_pc.h. Would it be more appropriate for these
> calls to mimic pp_read and pp_write?
Not at all: pp_read and pp_write are for doing IEEE 1284 data/address
transfers, whereas parport_read_data/parport_write_data ===
PPRDATA/PPWDATA.
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 Aug 14 2000 - 12:26:43 EDT