Messages in this thread |  | | | Date | Mon, 26 Jul 1999 10:16:09 +0200 | | From | Roger Larsson <> | | Subject | Re: Microsecond resolution timers - final word |
| |
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/
|  |