Hi Ulrik,
in my opinion it should be the responsibility of the devAsynInt32Array device
support to convert the data depending on the FTVL field. The idea with Int32 was
that registers up to 32 bits should be supported.
The documentation says:
"Note that hardware may have registers with smaller sizes, e.g. 16 bit
registers. The standard interfaces can still be used by setting the unused bits
to 0."
Thus, there is no need for 8 and 16 bit interfaces.
But that means your driver has to "blow up" the data by a factor of 4 to satisfy
the asynInt32Array interface and the device support must shrink the data to the
correct size depending on FTVL. Just to skip the check on FTVL and map longints
to 4 bytes does not do the job.
Dirk
Pedersen, UK (Ulrik) wrote:
Hello,
I've just upgraded from using asyn 4-6 to 4-8 and discovered that a
small part of my driver support has broken. My driver support retrieves
a byte-wide array from the device and uses asyn Int32Array interface to
send this to a waveform record with the FTVL field set to "CHAR". The
new version of asyn has introduced a check of this field in
devAsynInt32Array.c initCommon and fails if the field is not set to
"LONG" or "ULONG".
As my data is only byte-wide, I don't want to fill it into a 32bit wide
array and set FTVL to "LONG" as that would send out 4 times as much
data. I guess the "proper" fix would be to implement int8Array and
int16Array interfaces in devAsyn... Is anyone up for that?
For now, I have just rebuild my own version of asyn with this particular
check commented out. This way seems to work ok for now as the client is
requesting the data type from the WF record and it seems to just "do the
right thing" and retrieves a byte-sized array. I must admit that I don't
fully understand if commenting out this type checking has any
complicated implications that may break other stuff...
Cheers,
Ulrik
--------------------------------------------------------------------
Ulrik Pedersen phone: +44(0)1235-778580
Software Engineer email: [email protected]
Diamond Light Source Ltd.
Rutherford Appleton Laboratory,
Chilton, Didcot
OxfordShire OX11 0DE
--------------------------------------------------------------------
--
Dr. Dirk Zimoch
Computing and Controls
Paul Scherrer Institut
phone +41 56 310 5182
fax +41 56 310 4413
- Replies:
- RE: waveform problem with asyn 4-8 Mark Rivers
- RE: waveform problem with asyn 4-8 Mark Rivers
- References:
- waveform problem with asyn 4-8 Pedersen, UK (Ulrik)
- Navigate by Date:
- Prev:
waveform problem with asyn 4-8 Pedersen, UK (Ulrik)
- Next:
RE: waveform problem with asyn 4-8 Mark Rivers
- 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:
waveform problem with asyn 4-8 Pedersen, UK (Ulrik)
- Next:
RE: waveform problem with asyn 4-8 Mark Rivers
- 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
|