Experimental Physics and
Industrial Control System

Carl Lionberger <[email protected]> · Thu, 13 Jan 2000 15:22:29 -0800

You might be able to get the functionality you want by linking soft/raw soft
mbbiDirect, mbbi, mbboDirect, and mbbo records to the appropriately sized vxWorks
global variable records.   It looks to me like raw soft would be used with the
mbbo and mbbi so that the pattern number conversion would get done but the soft
would work with the direct records because it would still do the VAL to bit field
conversion.   Access to long types would be possible using the longin and longout
vxWorks variable support with appropriate SHFT and NOBT values in the soft
records.

I like your proposal too.  While we're talking about it, I'd like to see
mbbiDirect and mbboDirect support added.  Also, it would be nice if support for
RVAL were available so that record-level conversions could be used.

    Carl

William Lupton wrote:

> Dear all,
>
> We realized yesterday that the VxWorks global variable device support
> does not support selection of an individual bit (for bi/bo) or a range
> of bits (for mbbi/mbbo) from the underlying global variable. Device
> support for bi/bo simply copies a 'short' into .VAL and for mbbi/mbbo
> copies a 'long'.
>
> This hasn't been in an issue for us in past applications but now we have
> a case where a device is mapping extensive data structures, including
> some words where we would like to map individual bits on to bi/bo or
> ranges of bits on to mbbi/mbbo, into VxWorks memory. We would like to
> use the global variable device support to access these data structures.
>
> Here is a proposal:
>
> 1. extend the VxWorks global variable device support (INST_IO version) so
>    the link string, which is currently of the form
>
>    [ "*" ] name [ "[" index "]" ]
>
>    is of the form
>
>    [ "*" ] name [ "[" index "]" ] [ keyword "=" value ] ...
>
>    where the keyword/value pairs carry extra configuration information
>
> 2. keyword names would be case-independent and abbreviable (ambiguous
>    abbreviations would refer to that keyword which was first supported;
>    this guarantees backwards compatibility); initially, two keywords
>    would be supported
>
>    name         value                           default
>    ----         -----                           -------
>
>    start        bit number of lsb (0-31)        -1
>    type         type of underlying var.         as at present (*)
>
>    "start" specifies the same information that the "S" field does (by
>    convention) for VME_IO; the default of -1 means that the entire
>    variable is copied (as at present; needed for backwards compatibility)
>
>    "type" specifies the type of the underlying global variable; currently
>    this is implied by the record type; it would be particularly useful to
>    be able to specify that a bi/bo comes from a long, which is not possible
>    at present; the type names are the C names (with no support for "unsigned")
>    and are case-independent and abbreviable
>
> 3. white space is permitted everywhere (and is ignored, as at present)
>
> 4. note that bo/mbbo support may (strictly) require use of a semaphore to
>    cover the case where several records which access the same word are
>    processing concurrently (I recall an earlier discussion that resulted
>    in the use of intLock()/intUnlock(); one could add taskLock()/taskUnlock()
>    instead of a semaphore?)
>
> Here are some examples:
>
> assume that ssss is a 'short' global variable whose value is 0x1234 and
> llll is a 'long' global variable whose value is 0x12345678
>
> 1. bi: ssss s=4
>
>    VAL field is set to ssss's bit 4 (1)
>
> 2. bi: llll s=31 t=long
>
>    VAL field is set to llll's bit 31 (0)
>
> 3. mbbo: ssss s=8 t=short
>
>    NOBT bits of ssss, starting at bit 8, are set to VAL (VAL masked to NOBT
>    bits and shifted left by 8 bits)
>
> Comments?
>
> William

--
//
// Carl Lionberger                              [email protected]
// Computer Systems Engineer                    Voice   (510) 486-7503
// Engineering Division                         Fax     (510) 495-2957
//              Berkeley National Laboratory    (LBNL)
//

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System