Tim Waugh (tim@cyberelk.demon.co.uk)
Fri, 28 May 1999 18:42:06 +0100 (GMT)
On Wed, 26 May 1999, Sean C. Payne wrote:
> With that in mind, any good reference to get me started? C
> programming was a class almost a decade ago... I'm a network admin
> not a programmer :-) but hey I'm up to trying.
I don't claim that this is exactly right, but something like this is the
basic skeleton:
#include <sys/io.h>
#define DATA(b) (b + 0)
#define STATUS(b) (b + 1)
#define nAck 0x40
int main ()
{
int data;
if (iopl (0x378, 3, 0))
/* Maybe not root? */
return 1;
for (;;) {
if (!(inb (STATUS(0x378)) & nAck)) break;
/* should delay here? */
}
data = inb (0x378);
...
}
(The idea is to wait for nAck to go low and then read the data lines.
There is more to do.)
> alarms. Rather than wade through miles of paper, I thought if there
> was an easy way to let it think it was printing but have Linux capture
> this I could then "massage" the output into various reports...
I can see it would be useful.
> Given that info, would I use a straight through cable or a
> laplink style cable? I assume that it would be possible to use either
> depending on the program? Which would you recommend?
I don't know much about the laplink pin-out, but you want nStrobe to go to
nAck. That way, you have a chance of getting ppuser on your side...
ppuser is basically the user-space interface into the parport code. It
appears as a device node, and you perform various ioctls on it to get
different things to happen, including grabbing port access, reading and
writing the various lines, and so on. The plan is also that by doing
select() on it you will be able to get to find out about interrupts too.
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 2.0b3 on Fri 28 May 1999 - 13:56:19 EDT