Thanks for the responses to my request:
Ric Claus wrote:
>
> 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 will give Gabor's suggestion a try. I will use various standard
records with a common device support layer. The various board functions
will be accessed through the "signal" field in the VXI_IO structure.
Unfortunately this means that the DB designer has to know which record
type goes with which "signal" since it clearly doesn't make any sense to
attach a bi record to a "signal" which is supposed to receive a DSP boot
file
name (a stringout record). This means there is much more overhead in
checking
this at the device support level and reporting proper error messages
than
with the kitchen-sink record. In addition there are all those dbCommons
and
alarms, etc which have just increased 100 fold. Hope I have enough
memory!
>
> 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. Calling db_post_events from the
> ISR seems to have no effect. There is really no need (currently) to
> call
> the process routine, but the record must be updated. What is the proper
> way to handle both of these modes of operation?
I have found two solutions that seem to work. In the first, my record
is marked passive and I call recGblFwdLink in the ISR to make the
records
attached to my record's interrupt status field process. In the second,
I call scanOnce in the ISR to make my record process. Processing my
record
also causes recGblFwdLink to be called by my RSET->process routine, with
the same effect as the first solution.
So now my questions are: Is it legal to call recGblFwdLinks and
scanOnce
from an ISR? The documentation mentions that it is legal to call
scanIoRequest
from an ISR, but it's not clear about scanOnce. It seems to work, but
perhaps it would be better to do a callbackRequest from the ISR that
calls
scanOnce or recGblFwdLink?
Secondly, in a number of my DSET->initRecord functions, I save a
pointer to
the record in my device-private structure so that I can have
asynchronous
access to the record. Is this a good idea? Is anyone planning on
dynamically
moving records around? Is there a record ID or handle through which I
can gain
asynchronous access to the record that I should be cacheing instead?
Clearly I
don't want to cache the record name and translate it to a record pointer
in an
ISR as that would take too long.
[snip]
Thanks again,
Ric
--
Ric Claus ([email protected], (415) 926-2697)
- References:
- rec/devSup advise needed Ric Claus
- Navigate by Date:
- Prev:
Re: rec/devSup advise needed John R. Winans
- Next:
Seeing forward links from SNL? swampler
- 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 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
|