Ric, re...
> I'm writing driver, device and record support for a set of custom VXI
> modules. These modules have several functions, but share a number of
> things like a subset of the VXI A16 registers, interrupt handling, etc.
> Because of the desire to keep things self consistent and efficient, I
> created one record type per module type. This makes for fairly messy
> device support, as there is a lot of checking going on to figure out
> which record field changed that caused the record to process. Does
> anyone have a cleaner way to deal with this? Perhaps something to the
> effect of using RSET->special to figure out which field caused
> processing
> and using that information (somehow) to tell RSET->process which
> DSET->process
> function to call? Perhaps call DSET->process in RSET->special directly?
I've used special() just as you've described to simplify record-support
code. Give your record a field you can use as a bitmap, e.g.
"Monitor Mask" MMAP SPC_NOMOD ASL1 DBF_ULONG NO 3 ...
In special(), set the bit associated with the field that has changed:
.
.
#define M_MRES 0x00000080
#define M_ERES 0x00000100
.
.
static long special(struct dbAddr *paddr, int after)
.
.
if (paddr->pfield == (void *)&pmr->mres) pmr->mmap |= M_MRES;
> Second, the records properly handle Is and Os from/to the modules when
> they are marked scan passive. However, the modules can also raise
> interrupts when they detect faults. I would like to get that
> information
> into record fields for display on an operator screen. Setting up for
> the I/O Event scan mode appears to lock out processing due to
> modification of record fields from operator screens.
One possibility is to use an EVENT record with SCAN = "I/O Intr" to
detect the interrupt and forward link to the scan-passive record.
Tim
- Navigate by Date:
- Prev:
Re: rec/devSup advise needed Andrew Johnson
- Next:
R3.13 App Devl Guide Janet B. Anderson
- 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: rec/devSup advise needed Marty Kraimer
- Next:
Re: rec/devSup advise needed John R. Winans
- 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
|