OK, to reply to my own e-mail here and update you all on my latest
endeavors on my driver. I have established a design where after a newline
'\n', I increase the delay before the next character in order for the
printer to catch up.
Here is my code to write to the printer:
while (curcount < count )
{
success = parport_claim_or_block(mydevice[0]);
switchport( minor );
mydelay = 1;
for ( i = 0; ((i < BUFSIZE) && (curcount < count)) ; i++)
{
if( get_user(chunk, buf + curcount))
return -EFAULT;
udelay(mydelay * 1000);
mydevice[0]->port->ops->write_control(mydevice[0]->port, \
command_set );
mydevice[0]->port->ops->write_data(mydevice[0]->port, chunk);
do {
k = 0;
for (j=0; j <= mydelay; j++)
{
my_status=mydevice[0]->port->ops->read_status(mydevice[0]->\
port);
if ( ! ( my_status && PARPORT_STATUS_BUSY ) )
k++;
}
if (chunk == '\n')
{
mydelay = 500
printk("chunk is newline\n");
}
else
{
printk("chunk is %c\n", chunk);
mydelay = 1;
}
} while ( k >= mydelay );
mydevice[0]->port->ops->write_control(mydevice[0]->port, \
command_set | PARPORT_CONTROL_STROBE);
udelay(1000);
mydevice[0]->port->ops->write_control(mydevice[0]->port, \
command_set );
curcount ++;
}
printk ("mydelay = %i\n", mydelay);
parport_release(mydevice[0]);
}
So, basically, it claims the port, then causes the switch to go the
appropriate connector. It then gets a character from the user buffer.
The delay is there so the printer can catch up. This is sort of the
problem. I cannot seem to get a reliable indication of whether the
printer is still busy or not. If busy is low (the loop to make sure that
the busy low isn't spurious), then the printer should be ready for the
next character, right? So then if I send it the next character, it
doesn't always get there unless my delay is exhorbitently large.
Where can I get more information on this?
James Klaas
On Thu, 4 May 2000, Nordic Boy wrote:
> 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 : Fri May 05 2000 - 13:32:54 EDT