> but I cannot give a value to mbbo greater than (2^16)-1 (e.g. the value of a 32-bit register)
I don't think that is true. I just did a test using asyn/testEpics. I changed devDigital.db as follows:
corvette:asyn/iocBoot/ioctestEpics>git diff
diff --git a/testEpicsApp/Db/devDigital.db b/testEpicsApp/Db/devDigital.db
index 88bd630..63d36eb 100644
--- a/testEpicsApp/Db/devDigital.db
+++ b/testEpicsApp/Db/devDigital.db
@@ -16,7 +16,7 @@ record(longout,"asyndevLoUInt32") {
}
record(mbbo,"asyndevMbboUInt32") {
field(DTYP,"asynUInt32Digital")
- field(OUT,"@asynMask(digital,0,0xf,1.0) ")
+ field(OUT,"@asynMask(digital,0,0xffffffff,1.0) ")
field(ZRST,"zero")
field(ONST,"one")
field(TWST,"two")
@@ -34,8 +34,8 @@ record(mbbo,"asyndevMbboUInt32") {
field(FTST,"fourteen")
field(FFST,"fifteen")
field(ZRVL,"0x0")
- field(ONVL,"0x1")
- field(TWVL,"0x2")
+ field(ONVL,"0x100000")
+ field(TWVL,"0x200000")
field(THVL,"0x3")
field(FRVL,"0x4")
field(FVVL,"0x5")
So I increased the mask from 0xf to 0xffffffff, i.e. all 32-bits. I changed the ONVL and TWVL values to be larger than 16 bits.
I then ran the iocBoot/ioctestEpics IOC.
This is the output of dbl on that record:
epics> dbpr asyndevMbboUInt32 10
ACKS: NO_ALARM ACKT: YES ASG: ASP: (nil)
BKPT: 00 COSV: NO_ALARM DESC: DISA: 0
DISP: 0 DISS: NO_ALARM DISV: 1 DOL:CONSTANT
DPVT: 0xa6c240 DSET: 0x7f5a5eaf8200
DTYP: asynUInt32Digital EIST: eight EISV: NO_ALARM
EIVL: 0x8 ELST: eleven ELSV: NO_ALARM ELVL: 0xb
EVNT: 0 FFST: fifteen FFSV: NO_ALARM FFVL: 0xf
FLNK:CONSTANT 0 FRST: four FRSV: NO_ALARM FRVL: 0x4
FTST: fourteen FTSV: NO_ALARM FTVL: 0xe FVST: five
FVSV: NO_ALARM FVVL: 0x5 IVOA: Continue normally
IVOV: 0 LALM: 0 LCNT: 0 LSET: 0xa70120
MASK: 4294967295
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
MLOK: a0 f9 a4 00 00 00 00 00 MLST: 0
NAME: asyndevMbboUInt32 NIST: nine NISV: NO_ALARM
NIVL: 0x9 NOBT: 0 NSEV: NO_ALARM NSTA: NO_ALARM
OMSL: supervisory ONST: one ONSV: NO_ALARM ONVL: 0x100000
ORAW: 0 ORBV: 0
OUT:INST_IO @asynMask(digital,0,0xffffffff,1.0) PACT: 0
PHAS: 0 PINI: NO PPN: (nil) PPNR: (nil)
PRIO: LOW PROC: 0 PUTF: 0 RBV: 0
RDES: 0xa0d8e0 RPRO: 0 RSET: 0x7f5a5e880000
RVAL: 0 SCAN: Passive SDEF: 1 SDIS:CONSTANT
SEVR: INVALID SHFT: 0 SIML:CONSTANT SIMM: NO
SIMS: NO_ALARM SIOL:CONSTANT SPVT: (nil) STAT: UDF
SVST: seven SVSV: NO_ALARM SVVL: 0x7 SXST: six
SXSV: NO_ALARM SXVL: 0x6 TEST: ten TESV: NO_ALARM
TEVL: 0xa THST: three THSV: NO_ALARM THVL: 0x3
TIME: <undefined> TPRO: 0 TSE: 0 TSEL:CONSTANT
TTST: thirteen TTSV: NO_ALARM TTVL: 0xd TVST: twelve
TVSV: NO_ALARM TVVL: 0xc TWST: two TWSV: NO_ALARM
TWVL: 0x200000 UDF: 0 UNSV: NO_ALARM VAL: 0
ZRST: zero ZRSV: NO_ALARM ZRVL: 0x0
So you can see that ONVL and TWVL values are more than 16 bits.
I then set the asynTrace masks so I would get debugging output from the driver.
epics> asynSetTraceIOMask digital 0 6
epics> asynSetTraceMask digital 0 255
I then set the record VAL field to 1:
epics> dbpf asyndevMbboUInt32.VAL 1
2016/03/10 08:42:43.185 digital queueRequest synchronous
2016/03/10 08:42:43.185 digital 0 autoConnect
2016/03/10 08:42:43.185 digital uint32DigitalDriver:connect addr 0
2016/03/10 08:42:43.185 asynRecord: exception 0, asynExceptionConnect
2016/03/10 08:42:43.185 digital uint32DigitalDriver:writeInt32 value 1048576
2016/03/10 08:42:43.185 digital addr 0 write 1048576
2016/03/10 08:42:43.185 asyndevBiUInt32Bit0 devAsynUInt32Digital::interruptCallbackInput new value=1048576
2016/03/10 08:42:43.185 asyndevBiUInt32Bit1 devAsynUInt32Digital::interruptCallbackInput new value=1048576
2016/03/10 08:42:43.185 asyndevLiUInt32 devAsynUInt32Digital::interruptCallbackInput new value=1048576
2016/03/10 08:42:43.185 asyndevMbbiUInt32 devAsynUInt32Digital::interruptCallbackInput new value=1048576
2016/03/10 08:42:43.185 asyndevMbbiDirectUInt32 devAsynUInt32Digital::interruptCallbackInput new value=1048576
2016/03/10 08:42:43.185 asyndevMbboUInt32 devAsynUInt32Digital process value 1048576
DBR_STRING: "one"
2016/03/10 08:42:43.185 asyndevBiUInt32Bit0 devAsynInt32::getCallbackValue from ringBuffer value=1048576
2016/03/10 08:42:43.185 epics> asyndevBiUInt32Bit1 devAsynInt32::getCallbackValue from ringBuffer value=1048576
2016/03/10 08:42:43.185 asyndevLiUInt32 devAsynInt32::getCallbackValue from ringBuffer value=1048576
2016/03/10 08:42:43.185 asyndevMbbiUInt32 devAsynInt32::getCallbackValue from ringBuffer value=1048576
2016/03/10 08:42:43.185 asyndevMbbiDirectUInt32 devAsynInt32::getCallbackValue from ringBuffer value=1048576
So you can see that the driver wrote the value 1048576, which is hex 0x100000.
I then set the VAL field to 2 and again the driver wrote the expected value of 2097152= 0x200000.
epics> dbpf asyndevMbboUInt32.VAL 2
2016/03/10 08:49:55.087 digital queueRequest synchronous
2016/03/10 08:49:55.087 digital uint32DigitalDriver:writeInt32 value 2097152
2016/03/10 08:49:55.087 digital addr 0 write 2097152
2016/03/10 08:49:55.087 asyndevBiUInt32Bit0 devAsynUInt32Digital::interruptCallbackInput new value=2097152
2016/03/10 08:49:55.087 asyndevBiUInt32Bit1 devAsynUInt32Digital::interruptCallbackInput new value=2097152
2016/03/10 08:49:55.087 asyndevLiUInt32 devAsynUInt32Digital::interruptCallbackInput new value=2097152
2016/03/10 08:49:55.087 asyndevBiUInt32Bit0 devAsynInt32::getCallbackValue from ringBuffer value=2097152
2016/03/10 08:49:55.087 asyndevMbbiUInt32 devAsynUInt32Digital::interruptCallbackInput new value=2097152
2016/03/10 08:49:55.087 asyndevMbbiDirectUInt32 devAsynUInt32Digital::interruptCallbackInput new value=2097152
2016/03/10 08:49:55.087 asyndevMbboUInt32 devAsynUInt32Digital process value 2097152
DBR_STRING: "two"
2016/03/10 08:49:55.087 asyndevBiUInt32Bit1 devAsynInt32::getCallbackValue from ringBuffer value=2097152
epics> 2016/03/10 08:49:55.087 asyndevLiUInt32 devAsynInt32::getCallbackValue from ringBuffer value=2097152
2016/03/10 08:49:55.087 asyndevMbbiUInt32 devAsynInt32::getCallbackValue from ringBuffer value=2097152
2016/03/10 08:49:55.087 asyndevMbbiDirectUInt32 devAsynInt32::getCallbackValue from ringBuffer value=2097152
So I don't see any evidence that the values written by the mbbo record are limited to 16 bits.
Mark
________________________________________
From: [email protected] [[email protected]]
Sent: Thursday, March 10, 2016 8:29 AM
To: Mark Rivers
Cc: [email protected]
Subject: RE: mbbo/mbbi and bits subset
ok,
but I cannot give a value to mbbo greater than (2^16)-1
(e.g. the value of a 32-bit register)
Regards,
Gennaro
On Thu, 10 Mar 2016, Mark Rivers wrote:
> Hi Gennaro,
>
> The mbbo record has 16 enum choices. However, the values associated with each enum choice are 32-bit integers. So you can access all 32 bits in your register using an mbbo record.
>
> Mark
>
> ________________________________________
> From: [email protected] [[email protected]]
> Sent: Thursday, March 10, 2016 8:19 AM
> To: Mark Rivers
> Cc: [email protected]
> Subject: RE: mbbo/mbbi and bits subset
>
> Hi,
> I just realized that a mbbo can contain up to 16 bit value...
> it is possible to specify that a record can contain a 32 bit value ?
>
> the record documentation does not provide this information...
>
> Regards,
> Gennaro
>
> On Thu, 10 Mar 2016, [email protected] wrote:
>
>>
>> Hi Mark,
>> I did it with your suggestion by asynMask and everything works fine !!
>>
>> Thanks,
>> Gennaro
>>
>> On Thu, 10 Mar 2016, Mark Rivers wrote:
>>
>>> Hi Gennaro,
>>>
>>> You can do what you want using the asynUInt32Digital support and the
>>> @asynMask INP syntax.
>>>
>>> record(mbbo,"Acquire") {
>>> field(DTYP,"asynUInt32Digital")
>>> field(OUT,"@asynMask(myPort , 0, 0x3 , 1.0) ")
>>> field(ZRST,"Start acquire")
>>> field(ONST,"Stop acquire")
>>> field(ZRVL,"0x2")
>>> field(ONVL,"0x3")
>>> }
>>>
>>> You can use multiple mbbo/mbbi records to access different adjacent bits in
>>> your register using this technique.
>>>
>>> The asyn device support uses the NOBT, SHFT, and MASK fields of the
>>> mbbo/mbbi records documented here:
>>>
>>> https://wiki-ext.aps.anl.gov/epics/index.php/RRM_3-14_Multi-Bit_Binary_Output
>>>
>>> Mark
>>>
>>>
>>> ________________________________________
>>> From: [email protected] [[email protected]] on
>>> behalf of [email protected] [[email protected]]
>>> Sent: Thursday, March 10, 2016 4:54 AM
>>> To: [email protected]
>>> Subject: mbbo/mbbi and bits subset
>>>
>>> Hi,
>>> I'm using mbbo and mbbi record types to write and read
>>> some registers from/to ASYN driver I'm developing;
>>>
>>> some registers refers to a single aspect of acquisition
>>> (e.g. channel threshold) and with a simple mbbo record
>>> to write and a mbbi record to read back, everything works
>>> fine...
>>>
>>> other registers refers to a setup/control functions
>>> and using the same mbbo/mbbi approach works fine if
>>> the user address (read/write) every time the whole register;
>>>
>>> I know mbboDirect for bitwise access of a record value but
>>> is there a method to address (read/write) through a record
>>> a "bits subset" of a "main" mbbo record ?
>>>
>>> e.g. acquisition control:
>>>
>>> bit[16...2] <don't care>
>>>
>>> bit[1...0]
>>> 11 stop acquisition
>>> 10 start acquisition
>>> 01 do something...
>>> 00 do something...
>>>
>>> which is a simple method to access "directly" bitset [0...1]
>>> in order to have a record I can use to write 11 (3) to stop acquisition,
>>> 10 (2) to start acquisiton and so on ?
>>>
>>> Thanks in advance,
>>> Gennaro
>>>
>>> --
>>> Gennaro Tortone
>>> INFN Napoli
>>> Italy
>>> tel: +39 81 676169
>>>
>>> "Computer Science is no more about computers
>>> than astronomy is about telescopes."
>>> - Edsger Dijkstra
>>>
>>>
>>
>>
>
> --
> Gennaro Tortone
> INFN Napoli
> Italy
> tel: +39 81 676169
>
> "Computer Science is no more about computers
> than astronomy is about telescopes."
> - Edsger Dijkstra
>
>
--
Gennaro Tortone
INFN Napoli
Italy
tel: +39 81 676169
"Computer Science is no more about computers
than astronomy is about telescopes."
- Edsger Dijkstra
- References:
- mbbo/mbbi and bits subset [email protected]
- RE: mbbo/mbbi and bits subset Mark Rivers
- RE: mbbo/mbbi and bits subset [email protected]
- RE: mbbo/mbbi and bits subset [email protected]
- RE: mbbo/mbbi and bits subset Mark Rivers
- RE: mbbo/mbbi and bits subset [email protected]
- Navigate by Date:
- Prev:
RE: mbbo/mbbi and bits subset [email protected]
- Next:
stream protocol question: ASCII hex to 32-bit float Kevin Peterson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: mbbo/mbbi and bits subset [email protected]
- Next:
Re: mbbo/mbbi and bits subset Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·