VxWorks global symbol table device support

Carl Lionberger, CALionberger@lbl.gov

William Lupton, WLupton@keck.hawaii.edu

07 Nov 1996

VxWorks gives the programmer access to a library of symbol table support routines and provides a global symbol table which contains all external variable and function references in the system. The device support modules described here allow selected record types to read and write variables referenced by name. This capability allows EPICS to monitor and influence VxWorks-runnable code which was written without any knowledge of EPICS; the code needs only to have its critical variables declared externally, that is, left non-static outside any function definitions in the usual `C' manner.

Device support has been provided for ai, ao, longin, longout, stringin, stringout and waveform record types. These seven device support modules provide the ability to read and write double, long, and string types respectively (waveform uses type of waveform record; input and waveform records read and output records write. The device type "vxWorks Variable" is defined in the sdr source file "devSup.ascii.". The name of the VxWorks symbol desired is obtained one of two ways, depending on whether the LINK field is set to CONSTANT or INST_IO.

CONSTANT

The name of the vxWorks global variable is derived from the record name by stripping off any prefix ending with the first ":" and any suffix starting with the last ";". An underscore is automatically prefixed.

For example: "ppp:fred;sss" refers to the vxWorks global variable "_fred".
The intention is that the prefix would refer to the IOC and the suffix would distinguish references within an IOC. Suffixes and prefixes are optional.

INST_IO

The string value of the link field is assumed to be of the form:
[ "*" ] name [ "[" index "]" ]
where quoted items are literal and square brackets imply optional items. White space is ignored. The leading "*", if specified, implies that the variable in question contains the address of the desired data. The name is the name of the vxWorks global variable (a leading underscore is added). The optional array index is multipled by the data element size (e.g. sizeof(char), sizeof(long) or sizeof(double)) and applied as an offset to the data address.

For example:

DIRECT: "fred" refers to the value of the vxWorks global variable "_fred"; INDIRECT: "*fred" refers to the value whose address is the value of the; vxWorks global variable "_fred"; INDEXED: "fred[1]" assumes that the vxWorks global variable "_fred" is an array and refers to its second element
: INDIRECT + INDEXED: "*fred[1]" assumes that the vxWorks global variable "_fred" contains the address of an array and refers to the second element of the array

Note that the interpretation of the "*" operator is not the same as in C. For example, "fred" and "fred[0]" are the same and "*fred" and "fred[0]" are not the same. In this version of the driver, the value of the pointer is read at run-time rather than initialisation.

Finally note that strings are not treated any differently from longs or doubles in that the address returned from this routine is simply the address of the data. "fred" is the entire string. "fred[2]" starts at the third character of the string. Symbol table lookup is performed only at record init time; the resulting pointer is stored in the DPVT field. (The indirection, if present, is resolved at run time.) If the symbol is not found an illegal NAME field error is posted and DPVT is set to NULL. Processing consists of reading or writing the VAL field using the pointer, unless the pointer is NULL, in which case the device support module exits immediately. No value conversion is performed; it is assumed that the symbol refers to a variable of the same type as the VAL field. String operations are restricted to the 40 character size of the string record VAL fields and null termination is enforced.

No exclusion or interlocking with other code using the referenced variable is provided. This must be dealt with on a case-by-case basis. Typically the VxWorks code will have to poll for its input variables (from"write" records) and EPICS will poll the code's output variables with suitable SCAN values (from "read" records).

This software is part of the standard EPICS release. The INST_IO feature was added 11/96.