| Here is a little toy program that does single character qios from device
"DEVICE". Just define a logical device to be the real name of the
device you are reading from. There are all sorts of 1+ es possible.
For example, if you wish to read from several different devices,
then use QIO and specify an event flag rather than using QIOW. This
will return immediately rather than waiting for the character. Then
you will have to test the event flags to find out when something
has come in (see the system service $WFLOR).
Does this help, or have I answered a simpler question than you were
asking?
Burns
C
IMPLICIT NONE
INTEGER*2 iosb(4)
external io$_readvblk,ss$_normal
integer*2 count
integer sys$qiow,i,sys$assign
integer channel,ifunc,istat
byte ibuf(4096)
c get a channel for the device to read from
istat=sys$assign('device',channel,,)
if (istat .ne. %loc(ss$_normal))call lib$signal(istat)
ifunc = %loc(io$_readvblk)
c Read a single character from the device (%val(1) is the count)
10 istat=sys$qiow(,%val(channel),%val(ifunc),iosb,,,ibuf,
1 %val(1),,,,)
if (istat .ne. %loc(ss$_normal))call lib$signal(istat)
c do something with the character in the buffer. In this case,
c write it out
write (6,22)ibuf(1)
22 format(1x,1a1)
goto 10
END
|
| More information.
1. If each process is dedicated to a particular port for I/O, 20 devices
that would require 20 processes within the system. Future expansion
to use more units will be a problem.
2. Would use of event flag easily be implemented for large number of
similar devices? Please share more hints.
3. Scanning of each unit takes time. Is there any way to improve the
efficiency with or without QIO?
4. Each device requires polling and hand shake protocols, eg ACK and
NACK etc. Can the example handle it effectively?
5. The project will be run on a dedicated uVAX.
Again, I would appreciate for any help.
Regards,
|
| 1. You should not NEED one process per port. If you use $QIO rather
than $QIOW, the I/O request will be posted, but you will get control
back immediately. You are then free to issue a QIO to the next
port, and so on.
2. There are a limited number of event flags, so I would say that
with 20+ ports to monitor, you should use ASTs rather than event
flags. Using an AST simply means that you tell VMS the address
of a routine it should call when the I/O is complete. The nice
part is that you get to pass this routine a parameter called ASTPRM.
So essentially what you do is to issue the QIO for each channel.
Specify an AST routine which will be called when data comes in from
the port. Also specify an ASTPRM which indicates which port it
is (these are all arguments to SYS$QIO..see the system services
manual). In the ast routine look at ASTPRM to see which port the
data came from, and process it.
3. With ASTs you would not have to scan to find out which event
flag was set. I assume this is what you meant.
4. Well, the example can't do very well, but remember that you
can really do anything you want with ASTPRM. You could make it
an address to a table of anything you want. In a simpler case,
you could divide it so that one byte contained the channel number,
and one byte contained a state number. The state number could drive
a table to tell you what to do next in a protocol sequence).
Regarding polling, I'm not sure what you need to do. You can set timeouts
on QIOs so, for example, your AST routine would be called if either
data comes in, or no data has come for 10 seconds. You can see
if there is data and if not, send a request to the port.
I would try writing a toy program in your favorite language to try
out these features. You probably should have at least two terminals,
preferably 3 (one for debugging, two to simulate ports) and just
see what ASTs and event flags do. You may want to check out what
causes a QIO to terminate as well. My example in .1 terminates
with each character because I have set the length to 1. If you
set it higher, you can cause it to terminate if either certain
characters appear (ACK, NAK, carriage return, etc) or if a certain
number of characters come, etc. Lots of choices. Once you see
what QIOs can do for you, then just let your imagination go...there
are lots of possibilities.
I hope this helps...feel free to ask more questions.
Burns
|
| A quick comment to .3:
If your AST routine needs more info, you can build a buffer that
has overhead information (possibly an IOSB, etc.), followed by the
actual data buffer for the QIO, and pass the address of this buffer
as ASTPRM.
I work on an application that works like this. Buffers are removed
from a free buffer queue, initialized, and used for QIO operations.
When the AST fires the buffer is post-processed and eventually returned
to the free buffer queue.
|