Yes, I am finding that out.
OK, lets talk about strobes for a moment then.
The IEEE docs say that after the bits are on the line the host sends a low
pulse on HostClk(nStrobe). (HostClk is some timing function?) I assume
this is done using something like
"frob_control(port, PARPORT_CONTROL_STROBE);".
The peripheral then sets Ptr(nAck) low and PtrBusy(Busy) low. Would we
then read this using something like "status = read_status(port)" and
"if (status && (PARPORT_STATUS_ACK | PARPORT_STATUS_BUSY))" after which
another byte can be sent.
I noticed that the lp drivers put a delay in. Do you know why?
James Klaas
On Thu, 4 May 2000, Philip Blundell wrote:
> In message <Pine.GSO.4.21.0005031743540.8423-100000@broomstick.cs.albany.edu>,
> Nordic Boy writes:
> > {
> > if( get_user(chunk, buf + curcount))
> > return -EFAULT;
> >
> > mydevice[0]->port->ops->write_data(mydevice[0]->port, chunk);
> > /* write the data from the user to the port */
> > curcount ++;
> > }
>
> What port mode are you trying to use here? If it's compatibility mode you
> will need to provide explicit strobes.
>
> p.
>
>
>
-- 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 : Thu May 04 2000 - 08:19:35 EDT