bruce@bnr-vpa.UUCP (Bruce Townsend) (11/23/88)
I am trying to use the gpio 16-bit parallel interface card on
the HP9000s825 (HP-UX rel 2.0), to continuously read or write
data at a rate controlled by the equipment connected to the
gpio card. The data rate is clocked at 100K 16-bit words/sec,
and when a datum is presented to the gpio card, it must be read
before the next datum arrives, or it is lost.
The problems I have encountered are:
1) The gpio will adequately read (or write) data at 100K words/sec,
but only in 64K byte chunks. When asked to read more, gaps of
up to 20 msec occur, and so up to 2000 words are lost. HP had
promised that the aquisition rate would be maintained continuously,
for a read to memory, limited only by the size of physical memory
available.
2) Software interrupts do not interrupt a read or write on the gpio.
As a single transaction can last many seconds (5M @ 100K/sec =
50 seconds), the ability to interrupt in the middle is important.
3) Hardware interrupts do not seem to be supported. Neither the EIR
(external int. request) line not the two status lines (ST0, ST1),
seem to be able to interrupt the gpio.
Is there anyone who knows about these deficiencies? Are they being
addressed for Rel 3.0? The HP9000s500 supported continuous reads of
up to 512K bytes, and both s/w and h/w interrupts were supported.
Hopefully the s825 can be made to work also.
regards,
--
Bruce Townsend (bnr-vpa!bruce) Phone: (613) 763-3008
Bell-Northern Research Usenet: {utzoo, utcs}!bnr-vpa!bruce
P.O. Box 3511, Station C, Ottawa, Ontario, Canada, K1Y 4H7suzyz@hpisoa1.HP.COM (Susan Dedo) (12/01/88)
> 1) The gpio will adequately read [...]. HP had > promised that the aquisition rate would be maintained continuously, > for a read to memory, limited only by the size of physical memory > available. Hmmm. Sounds like your local SE needs to be contacted. If you are an SE, call the Series 800 on-line support group. > 2) Software interrupts do not interrupt a read or write on the gpio. > As a single transaction can last many seconds (5M @ 100K/sec = > 50 seconds), the ability to interrupt in the middle is important. What is meant by "software interrupt", Control-C? Sigalarm? I/O is not always interruptable. At some point during the I/O, the driver sleeps at a non-interruptable priority. This is a must. Imagine I/O in the simpilist of terms: io_routine () { lock memory for I/O start the I/O sleep unlock the memory } First the memory is locked, then the I/O is started. Next we sleep waiting for the hardware to complete. Suppose a signal, say ^C, is received. When a process receives a signal it has some choices of how to handle that signal, depending upon its state (running, runable, sleeping, zombie). The process can either: 1. immediately jump out of io_routine() and return back to who ever called io_routine(). In such a case, the locked memory would never be unlocked. This is a bad thing to happen. 2. return to the instruction immediately following the call to sleep(). In this case, "unlock the memory". So now the memory is unlocked and could be allocated to someone else. Problem: the hardware is still writing to what it believes is the locked memory allocated for its I/O. This is a very bad thing to happen. Our solution: do not allow this instance of "sleep" to be interrupted. The only way to inform the hardware that it should prematurely stop, is to have the I/O transaction timeout. Then the driver has the ability to stop the hardware. I would suggest that your transactions be broken down into smaller chunks, but it appears doing so will cause data loss. > 3) Hardware interrupts do not seem to be supported. Neither the EIR > (external int. request) line not the two status lines (ST0, ST1), > seem to be able to interrupt the gpio. > Where are you reading this information, a manpage? (What manpage?) The reason I ask is that the 27114A can not interrupt via the ST0 or ST1 lines. The card can only interrupt, once the card is enabled to recognize interrupts, by the peripheral pulling on the ATTN line. How is the card enabled to interrupt (What commands are you using)? ---------------------------------------------------------------- Susan Dedo
dc@hpdstma.HP.COM (Daniel Cordey) (12/07/88)
20 ms seems too long...Is your process runing at a real-time priority ? Daniel Cordey Systems Escalation Management
bruce@bnr-vpa.UUCP (Bruce Townsend) (12/09/88)
In article <1310003@hpdstma.HP.COM> dc@hpdstma.HP.COM (Daniel Cordey) writes: >20 ms seems too long...Is your process runing at a real-time priority ? > No; perhaps if it were, the gap could be reduced to 10ms? 5ms? even 1ms? That is still too long; the samples are presented/read by the peripheral at a regular rate up to 100K words/sec. That means that the interval between any given pair of sample read/writes can be no longer than 10 usec. Clearly, continuous DMA into physical memory is required. -- Bruce Townsend (bnr-vpa!bruce) Phone: (613) 763-3008 Bell-Northern Research Usenet: {utzoo, utcs}!bnr-vpa!bruce P.O. Box 3511, Station C, Ottawa, Ontario, Canada, K1Y 4H7