Jens,
What I have done in the past is to support I/O interrupt scanning for
these sort of variables. Then whenever a write is initiated on a
variable, any other variables which are read in the same operation but
which are set to be I/O interrupt scanned are automatically updated.
What the driver has to recognize is that a set of variables all have the
same command string, and parse out different bits of the response string
to each one.
Cheers,
Nick Rees
Principal Software Engineer Phone: +44 (0)1235-778430
Diamond Light Source Fax: +44 (0)1235-446713
> -----Original Message-----
> From: Jens Rekow [mailto:[email protected]]
> Sent: 17 November 2005 15:38
> To: [email protected]
> Subject: record/device support general style question
>
>
> Hi All,
>
> it is rather an architectural/style question that I ran into
> working on
> the device support for a message based serial/ethernet device
> (yes, it is
> the LoCuM4).
> Imagine there is a command that retrieves various status values binary
> encoded in a string (bytes, shifted to printable
> characters...). I would
> like to serve several PV's out of that. (It wouldn't make
> sense to put so
> much information in just one record, mbbi, whatsoever)!
>
> As always there are different ways to deal with that:
> Worst case that I can think of is to have AsynDriver device
> support for
> each record, so EACH time ONE of them is processed there would be I/O
> transaction at the interface for retrieving the whole status
> string and
> the tiny bit (literally!) of interest will be extracted.
>
> My way so far is another: There is one AsynDriver-powered record
> (stringin) which retrieves and holds the status string. That
> value is read
> by a longin record via dbGetField() in a standard device
> support, which
> extracts the information and distributes to all the other
> relevant records
> via dbPutField(). Thus these other records don't need any
> device/record
> support implementation themselves but are set remotely.
> Unfortunately this
> complicates handling the alarm/invalid states of these records.
>
> So the question is:
> Would it be better to have already my AsynDriver-powered record, which
> reads the status bytes, distributing the values to the
> different records
> via dbPutField()?
> Alternatively I like the idea of only one device support
> implementation
> for several records which is flexible using the INP field as a
> parameter...
>
>
> Any suggestions?
> What could be more 'stylish'?
>
> Thanks in advance,
> Jens
>
>
- Navigate by Date:
- Prev:
record/device support general style question Jens Rekow
- Next:
RE: record/device support general style question Liyu, Andrei
- 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: record/device support general style question Marty Kraimer
- Next:
RE: record/device support general style question Liyu, Andrei
- 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
|