Experimental Physics and
Industrial Control System

Carl Lionberger <[email protected]> · Mon, 28 Nov 2005 09:40:25 -0800

The thought was that the subarray record would be purely a soft record,
and any hardware device support would be for waveform records that the
subarray would read from. The MALM code makes sense in this context
because the API for the dbaccess (as Noburu alluded to) always starts at
element 0 of the source record. Therefore it is impossible to index an
element larger than the buffer space you have.
You might consider writing a device support suite which supports a
waveform record of the length you want and a couple of ao or longout
records which control the index and length of the reference into the
hardware..
Carl
Michael Abbott wrote:
I am writing device support for a subArray record so that I can read
small slices from a very large array provided by a device. The device
in question has limited memory, and so I cannot afford more than one
copy of this array in memory, namely the copy in the device driver
itself. My plan is to read the data like this:
    record(subArray, "SA")
    {
        field(DTYP, "My driver")
        field(INP,  "my driver's arguments")
        field(MALM, "1024")
        field(FTVL, "LONG")
    }
    $ caput SA.NELM 1024
    $ caput SA.INDX 1024000
    $ caput SA.PROC 0
    $ caget SA
Unfortunately there is one very interesting and annoying fly in the
ointment. In subArrayRecord.c:readValue we see the following two
lines of code:
    if (psa->indx >= psa->malm)
        psa->indx = psa->malm - 1;
Ooops. Most unhelpful!
This stupid code means that MALM, which is used to allocate the
storage used by the subArray record, also determines the maximum index
into the device array. I think this is missing the point of a
subArray; it certainly gets in my way.
Now, it turns out I am lucky: malm is used to allocate storage
*before* it calls my init_record, so I can fake malm back to the value
I want to to be. However, this is hardly very satisfactory, and is
going to have a mildly embarassing side effect:
get_{graphic,control}_double will return bogus values for the upper
limit on nelm.
Any thoughts on this?


--
Carl Lionberger
Control System Software Engineer
Berkeley National Laboratory (LBNL)
(510)486 7503

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System