AnsweredAssumed Answered

VRf-Serial_Buffering

Question asked by VRFuser on Jul 23, 1996
from: Greg Goebel / HP-MXD
      gvg@lvld.hp.com / 970-679-3030 / FAX 970-679-5971
to:   Alasdair Wilkie
date: Wednesday, 24 July 1996 1126 MDT

> A problem that I have thought about but not resolved.
>
> We have a series of instruments which output data in a continuous stream in
> RS232 format.
>
> We would like to be able to read this data into HP VEE and do some work on
> this data.
>
> The data is output fairly slowly, 5 sets of data every second.  Each set of
> data is about 30 bytes long.
>
> As we cannot access the instrument as we would an ordinary instrument can we
> get the data stored in a buffer and VEE to read the buffer at specific
> intervals?
>
> We are using VEE 3.12 on a PC with Windows 3.1/3.11
>
> Thanks in advance
>
> Alasdair
>
> as04@dial.pipex.com

Sir:

Actually, buffering is provided as a matter of course.   If you go into your
instrument configuration in VEE and do Direct I/O config, you'll see an entry
for the buffer size along with the other serial settings.  Serial data can
arrive and accumulate unread ... as a matter of fact, I wrote an article on
how the buffering works that I printed in EXCHANGE, might as well tack it
on here.

If you have more questions, let us know.


[%%] gvg



[VEE] VEE Serial Buffering Operation

* There's been a little confusion (among ourselves as well as other users)
about the operation of buffering under VEE serial ... we had a transaction
with a customer who was uncertain about how VEE handled buffering that
provided some interesting insights into this matter.

* The customer had a device that continuously sent back a frame of 12 binary
bytes every few dozen milliseconds; it had no handshaking capabilities.  He
was having trouble keeping the device synched up with his VEE program, though
a C program could do it fine.

I wrote two VEE programs, one to simulate the instrument and one to simulate
the customer's application program.  The one that simulates the instrument
looks like this:

   +-------+
   | Start |
   +---+---+
       |
   +---+---+
   |  DIO  | EXECUTE RESET
   +---+---+
       |
  +----+----+
  | Repeat  |
  |  Until  +--+
  +---------+  |
               |
       +-------+
       |
  +----+----+
  | Integer |
  +---------+
  | 0000:0  |
  | 0001:1  |
  | 0002:2  |
  | 0003:3  |                                            WRITE BINARY a BYTE
  | 0004:4  +---+------------------->+---------------+   +-----+
  | 0005:5  |   |                    | Concatenator  +-->| DIO |
  | 0006:6  |   |                +-->+---------------+   +-----+
  | 0007:7  |   +-->+---------+  |
  | 0008:8  |       | Counter +--+   +---------------+
  | 0009:9  |   +-->+---------+  |   | If/Then/Else  |
  | 0010:10 |   |  Clear         |   +--------+------+
  +---------+   |                +-->| A==255 | then +--+
                |                    +--------+------+  |
                |                                       |
                +---------------------------------------+

This little program resets the serial interface, and then goes into an endless
loop, sending an array of 12 bytes over serial; the first 11 bytes are numbers
0 to 11, while the 12th byte counts up from 0 to 255 through successive
transmissions of the array.  This gives an array that can be read on the
remote end and visually checked to see if there are sequencing or framing
errors.

The program on the receiving end is simpler -- it just reads the arrays and
displays them:

   +-------+
   | Start |
   +---+---+
       |                                 +--------------+
  +----+----+                            | AlphaNumeric |
  | Repeat  |                            +--------------+
  |  Until  +-----+                      | 00: 0        |
  +---------+     |                      | 01: 1        |
                  |                      | 02: 2        |
  +---------------+-----------------+    | 03: 3        |
  |              DIO                |    | 04: 4        |
  +-----------------------------+---+    | 05: 5        |
  | READ BINARY x BYTE ARRAY:12 | X +--->| 06: 6        |
  +-----------------------------+---+    | 07: 7        |
                                         | 08: 8        |
    +-------+                            | 09: 9        |
    | Start |                            | 10: 10       |
    +---+---+                            | 11: 237      |
        |                                +-------+------+
    +---+---+                                    |
    |  DIO  | EXECUTE RESET                  +---+---+
    +-------+                                | Delay |
                                             +-------+
                                             |   0   |
                                             +-------+

Notice the delay at the bottom of the loop ... this allows me to selectively
slow down the receiver so that data will arrive faster than it is read.  Note
also how I have set up a second thread to perform a RESET when needed.

* Anyway ... when I ran both programs and kept the receiver delay at 0, the
results stayed framed up indefinitely.  If I set the receiver delay to 0.15
seconds, then after the buffer was filled up, the receiver lost sync and
dropped frames.

Performing a RESET clears out the receiver buffer; when I set the receiver
buffer size to 120 bytes (you can do this through the VEE I/O menu -> Other
Instruments -> Edit Instruments -> Direct I/O Config) and reset the buffer,
ran the transmitter program for a minute or so, and then ran the receiver
program, it read the first ten frames and then got out-of-sync intermittent
frames.

This indicated that the first data put in the buffer was retained while
anything that arrived after the buffer has been filled was lost.

Since there was no handshaking in the customer's system, this was expected
behavior and the VEE program couldn't work as it was designed.  The C program
worked because it was faster. 

The customer's options were to provide handshaking, slow down the serial
transmission rate, or rewrite the program with the timing constraints in mind:
For example, allocate a large serial buffer and design the program so that it
would, every now and then, jump into a tight loop and read the data out of the
buffer into an array.  This would allow it to alternate between reading data
and processing it ... the customer would have to do some timing analyses and
tests to figure out the limits.

[<>]

Outcomes