Experimental Physics and
Industrial Control System

Allan Honey <[email protected]> · Tue, 3 Sep 2002 14:09:12 -1000 (HST)

Aloha

I have placed a new version of drvAscii in the keck website.

The main purpose of this release is to alleviate the occassional
loss of synchronization that occurs, which may or may not require
restarting the system (i.e. processor rebooting). The symptom of the
loss-of-synchronization problem is interminable 'semTake failed'
messages.

In addition, I tried to incorporate the many additional features,
that users of the system have requested. An attempt at enumerating
those features follows.

 *    1. Significant modifications, within drvAscii.c, in regards to 
 *     the handling of synchronization semaphores so as to alleviate 
 *     potential loss of read/write synchronization. Although the 
 *     synchronization problem was infrequent it sometimes required a 
 *     processor reboot in order to correct the problem. Hopefully, 
 *     synchronization will now be auto-magically re-established.
 *
 *    2. Analog records may now have 'REAL' specified in their parm fields,
 *     after the link specification and before the first prompt format
 *     field (e.g. @<link> REAL <prompt format> <response format>)
 *
 *     If an analog input record has the REAL attribute then the value 
 *     returned from the remote device is written into the record's VAL
 *     field and RVAL/ESLO conversions are bypassed. Note that also 
 *     bypasses the 'slope' record behavior. Similarly, analog output
 *     records will have their VAL values output to the remote device
 *     rather than their RVAL values. In general this eliminates the
 *     conversions to/fro real and integer which caused loss of
 *     precision, as well as, reducing the considerable complexity in using
 *     drvAscii for analog records.
 *
 *    3. The format-string delimiters no longer have to be '<' and '>'
 *     for all records. Now the first character follwing the link
 *     specification is assumed to be the field delimiter, with the pairs
 *     '<>', '()', '{}', and '[]' assumed, when the left hand delimiter
 *     is encountered. The following are now valid (on a record-by-record
 *     basis):
 *                  @/tyco/0 <status?> <%s>
 *                  @/tyco/0 (status?) (%s)
 *                  @/tyco/0 !status?! !%s!
 *                  @/tyco/0 *status?* *%s*
 *                  @/tyco/0 Xstatus?X X%sX
 *
 *    4. User specified framing routines can now be specified.
 *     With this release one can create their own input and output
 *     framing routines and have them override the default getFrame()
 *     and putFrame() routines. This allows one to do more sophisticated
 *     packet framing (e.g. a checksum could be added/checked).
 *
 *     To specify special framing routines one must download the library,
 *     they created, containing those routine, then register the 
 *     functions with drvAsciiSetTxFunc() and drvAsciiSetRxFunc(), all
 *     prior to iocInit. Note that a different set of framing routines 
 *     can be registered for each serial link. Also note that there are
 *     special requirements imposed on the framing routines. An example
 *     exists within drvAscii.c
 *     
 *    5. More extensive control of debugging information via link-specific
 *     debug records and via a drvAscii global variable drvAsciiDebugLevel.
 *
 *    6. Format specifications may now have embedded hex or octal bytes
 *     Said bytes must be of the form '\xnn' or '\ooo'. Those bytes are
 *     translated when the format specs are parsed during record init.
 *     For instance a prompt format such as <\x58\x59\x5a?> will result 
 *     in the string 'XYZ?' being output to the remote device.
 *     
 *    7. All numeric escape codes, that exist in output or input data
 *     streams, will be automatically translated. For instance a
 *     stringIn record with this prompt and response format '<%s?><%s>' 
 *     can be manipulated with "caput stringIn '\x58'" to result
 *     in a prompt of 'X?' being transmitted. This should simplify record
 *     manipulation for those apps which talk to multi-dropped devices
 *     whose addresses are leading non-printing ASCII bytes. The numeric
 *     escape codes need not result in printable ASCII characters, 
 *     that is, "caput stringIn '\x81'" is valid. However, beware that 
 *     drvAscii uses sprintf and sscanf so embedding a null byte will 
 *     cause unexpected behavior.
 *

Note that there is still no formal documentation for drvAscii, however, the
header of devAscii.c is getting very long :0)

I created 5 capfast drawings which can be used to play with and test
drvAscii (integerIn, integerOut, analogIn, analogOut, and strings), as well
as providing examples of record usage.

A test readme is included, as I tied two terminal server ports back-to-back
for simple testing without a remote device connected (drvAscii connects
to one and you telnet to the other, or write a task, or use cat, or ...
be more creative than me).

ftp ftp.keck.hawaii.edu
cd pub/epics/drivers/drvAscii/v2.0

cheers,
	Allan

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System