Experimental Physics and
Industrial Control System

Ric Claus <[email protected]> · Fri, 23 Aug 1996 15:26:40 -0700

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)

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System