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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: mbboDirect record and SHFT field |
From: | Mark Rivers <[email protected]> |
To: | 'Rod Nussbaumer' <[email protected]>, epics Techtalk <[email protected]> |
Date: | Thu, 14 Sep 2017 22:15:37 +0000 |
Hi Rod, FWIW, this is how the asyn device support handles .SHFT. For the asynUInt32Digital interface: static int computeShift(epicsUInt32 mask) { epicsUInt32 bit=1; int i; for(i=0; i<32; i++, bit <<= 1 ) { if(mask&bit) break; } return i; } The initialization for mbbi, mbbo, mbbiDirect and mbboDirect records all do the following: pr->shft = computeShift(pPvt->mask); The process functions for mbbo and mbboDirect do the following: if(pr->shft>0) rval >>= pr->shft; For the asynInt32 interface it is handled differently. In mbbi and mbbo initialization pr->mask <<= pr->shft; In mbbo processing: if(pr->shft>0) rval >>= pr->shft; So for devAsynUInt32Digital it is computing SHFT from MASK, while for asynInt32 it is computing MASK from SHFT. I am not sure of the logic behind this, but it was written by Marty Kraimer 13 years ago, and he usually got things right! Mark -----Original Message----- We're looking at device support written by a vendor, and there is a
database template that includes in a mbboDirect record with the .SHFT
field given a value in the EPICS runtime db. Since our database
configuration tool, tdct, doesn't provide for creating a DB with the
SHFT field set for that particular record type, I started looking... In the record reference manual for 3-14 record reference manual, it says
"the SHFT value is set by device support and is not configurable by the
user". The information in the accompanying table supports this,
indicating in the 'DCT' field of the table 'NO' for the SHFT field of
the record type. In the R3.14.12.3 dbd file for the mbboDirect, there exists the entry
"promptgroup(GUI_MBB)", suggesting that a database configuration tool
should be allowed to set the SHFT field. When the database is loaded on
an IOC, and the SHFT field has been initialized at dbLoadRecords time,
the field behaves as one might expect for that circumstance. Is that the intended behavior, and the docs are out of sync, or the
other way around? If the SHFT field should really only be set by device support, is there
a strong convention for that? The method I recall is to infer from a
bitmask supplied in the .OUT field, by counting the number of clear
least significant bits. Are there other conventions or preferences? Rod Nussbaumer Group Leader, Controls TRIUMF Vancouver, Canada |