Experimental Physics and
Industrial Control System

Jeff Hill <[email protected]> · Fri, 17 May 1996 14:48:12 -0600

> Additionally (I'm still not very familiar with the VXI standard so bear with me please), on
> our modules, there is an interrupt status register which is read and cleared during the interrupt
> acknowledgement cycle by the niCpu030 BSP (I'm not sure if this is the VXI standard method).  Since the
> resulting statusId value is not passed on to the ISR, there is no way to figure out what the source of
> the interrupt was when using the intConnect mechanism (and its variants).  I see three ways out of this:
> 1) use NI's niVxi library (YUCK!), 2) use the BSP's sysBusVXIIntConnect and sysBusIntMaskSet routines
> so that the ISR is passed the statusId value, 3) throw out the niCpu030's, use VME processors and handle
> the register directly.  How did you solve this problem?

Perhaps you will decide to hack the NI CPU 030 BSP so that the full 16 bit status id (which
is being read in sysBusIntInt()) is stored in an array indexed by the interrupt level.
You could then write a routine - say sysBusStatusIDGet() - which would return the
16 bit status id indexed by the current interrupt level. This routine would be called by the 
ISR. If you move to a new CPU then you will only be required to rewrite sysBusStatusIDGet().

Making particular EPICS drivers dependent on small changes to the BSP is a fairly common 
practice (when there is no other option).

>   One of the characteristics of these modules is that they can be set up to continue to operate even
> though the slot 0 controller has gone away (e.g. during a reboot to load a new database, etc.).  Of
> course, during this period, the niCpu030 can't field interrupts from the modules and so they must
> pend until it comes back.  This is not a problem for the modules.  However, it does mean that interrupts
> must be enabled in a controlled fashion, preferably at the point that interruptAccept goes TRUE in
> iocCore.  One can't simply ignore interrupts that have occured before interruptAccept goes TRUE as the
> App Dev Guide says since that could cause part of a handshake to be lost.  How do I best arrange this?
> It seems kind of nasty (resource use and fragmentation issues) to have to spawn a task in the driver that
> waits around for interruptAccept to go TRUE, enables interrupts and then exits.  Another option might be
> a callback, but I don't know how to trigger it.  Perhaps initHooks?  How do I know somebody else hasn't
> used it?  For the wish list:  It would be nice for drivers to be able to register a callback (with an
> argument) to be called at interruptAccept=TRUE time.

Perhaps it will be sufficient to avoid calling scanIoRequest() when interruptAccept is
FALSE (but otherwise keep track of handshakes as needed by the driver). Many
drivers currently call scanIoRequest() prior to when interruptAccept goes to
TRUE (most likely because they were written before interruptAccept was added
to EPICS - or were based on these early drivers).

We have run into OS difficulties if devices are interrupting during a vxWorks
control X reboot. To avoid this most drivers disable interrupts by setting a bit on the cards
involved in a control X handler (vx reboot hook) - see the many examples
in base/src/drv.

The device support init routine is called before and after interruptAccept is set to TRUE. If
you are writing the device interaction in driver support then call driver support from 
device support when you need to enable interrupts (by setting a bit on the card).

If your module does not allow interrupts to be enabled/disabled directly on card then place
all of the cards involved on a private interrupt level and call sysIntEnable(level) after
interruptAccept goes to TRUE.

> 
>   Some of the fields in the A24 areas of the modules are quite large, e.g., more than a few longins
> or longouts.  Are there any array records (ali/alo) floating around?  If not any objection if I invent
> them?  I'm not sure that that's the right solution yet, however.

Perhaps base/src/rec/waveformRec.{c,ascii} will be suitable?
The sub array record will allow indexing out portions of the wave form as needed.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System