Re: Microsecond resolution timers - final word

Roger Larsson (roger.larsson@skelleftea.mail.telia.com)
Mon, 26 Jul 1999 10:16:09 +0200


Robert Norris wrote:
>
> On Tue, Jul 27, 1999 at 08:24:06AM +0100, Tim Waugh wrote:
> > Is that 20-40 usecs response to an interrupt on the port? I'm finding
> > that the interrupt latency is around about that, at least by the time you
> > respond to the interrupt. Perhaps I'm doing something wrong though.
>
> No. It's not parallel port based (hell, it's not even pc based). Its a custom
> bit of hardware that uses three lines on the parallel port, and communicates
> using a simple serial-esque protocol. It transfers bytes bit-by-bit, using
> an ACK and DATA line.
>
> Here's an example. I send a bit on the data line, and the device responds
> by bringing the ACK line high .. I then have to bring ACK low and send the
> next data bit within 20-40 usecs.
>
> Is gettimeofday accurate enough for this?
>

You have to do this in a driver, the scheduling latency are too long
to run an ordinary process (there is hope that it can be brought down to
5 ms)

* Can you get an interrupt for each bit accepted?
* Maximum rate, timing from bit to ACK?

* Are you going to send a block of data on occasion?
* Do you mind blocking the whole computer during sends?
If no interrupt and yes to these two, you could probably
do with a loop using usleep(20)

* Or do you like to do this continuously?
I hope not! :-)

You might also want to look at RT-Linux (quite a different low level
approach)

On the HW side could you consider adding a buffer using some
programmable
logic? It sounds like a simple problem shifting out data at ACK rate.
With a FIFO buffer and some kind of computer interface... A evaluation
board should do it...

Regards,
Roger Larsson

-- 

The Internet interprets Windows as damage, and routes around it.

Roger Larsson Skellefteċ Sweden

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/