Lemme muddy the waters a little bit more…
Up in the "Read and Convert Parameters"…
Last couple of sentences… (my emphasis…)
"… The user
can configure the NOBT field, but the device support routines may set it, in which case the value given to it by the user is simply overridden. The device support routines
may also override MASK or shift it left by SHFT bits. If MASK is non-zero, only the bits specified by MASK will appear in RVAL."
I take from that, from the driver's point of view, 'MASK' is optional, and may or may not be used. If that's the case, seems to me I should be able to define whatever mask I want, and as long as I don't want to match more than 16 values, it should work
..So, if I define a mask in the driver that is 0x0303 for instance (bits 0,1,8, and 9), and set NOBT to 10, I should be able to match against 16 field values, even if the actual values I'm matching have values of "0,1,2,3, 256,257,258,259, 512,513,514,515,
768,769, 770,771" (I've already taken too much space, I'm not going to give them in binary as well ). As long as I only have <16 valid bit states that I'm looking for, seems that I should be able to use -any– combination of bits (if I can compute their actual
values, which I hope I got right).
I could add a calc record and figure some way to generate consecutive bits, but that seems like just adding an additional record that I don't really have to add, if I can define another way.
In the record reference manual on the EPICS wiki
||Number of Bits
||Number of hardware bits accessed. They must be consecutive.
It would be better if the introduction to this record type had pointed this out. I will chance that today - if I remember how to get into the wiki page.
From: Dudley, David
Sent: Friday, June 01, 2012 8:42 AM
To: Dalesio, Leo; firstname.lastname@example.org
Subject: Re: mbbi/mbbo Mask values
I am assuming that is defined somewhere?
Looking at the MBBI record definition, I see that Mask, ZRVl, ONVL, … FFVL are all ULONGS, which would allow a bit field to be defined that didn't depend on consecutive bits. Seems that the limitation is that NOBT defines MASK.
If NOBT was set to 0 (I would take that meaning as "don't define mask"), seems MASK 'should' be able to be manipulated.
Looking in the ether-ip driver, it doesn't look like mask from the record is even used. It builds it's own internally.
The limit/definition of the MBBx record types was that the bits were consecutive.
I think that you would have to use a calc record between the input and MBBx record to mask out the bits in between.