Experimental Physics and
Industrial Control System

Jure Varlec via Tech-talk <tech-talk at aps.anl.gov> · Thu, 27 Jan 2022 08:48:15 +0100

Hello Mark,

Thanks for the explanation, it helps a lot; I knew I was confused, of course,
but not exactly where the issue was. I often have problems with nomenclature as
various terms used in asyn are very context-dependent; in particular, I think I
lack some background information to understand the distinction between hardware
and software interrupts you make in this context. I surmise that, when you say
“hardware interrupts”, you refer to the interrupt sources that a driver can
enable or disable on the device, while with “software interrupts”, you refer to
the mechanism by which the interrupts are propagated from the driver to the
EPICS records, regardless of whether they originate in hardware or some software
event in the driver. Correct?

It appears, then, that the `asynUInt32Digital' interface has two distinct parts:
• `registerInterruptUser()' and `cancelInterruptUser()' deal with “software
  interrupts” and allow EPICS device support layer to subscribe to events from
  the driver;
• `{set,get,clear}Interrupt()' tell the driver to enable or disable particular
  hardware interrupts. The driver needs to override the default implementation
  of this interface to use it, like `ipUnidig' does.

But I may have misunderstood the distinction :)

In any case, as I had pointed out, asyn’s EPICS device support layer does not
have any calls to `{set,get,clear}Interrupt()'. So who does `ipUnidig' implement
this for? Some non-EPICS user?

Thanks,

Jure

Mark Rivers <rivers at cars.uchicago.edu> writes:

> Hi Jure,
>
>> I’m looking at `asynPortDriver::setInterruptUInt32Digital()’ which is documented to be “called when asyn clients call
> `pasynUInt32Digital->setInterrupt()’”.
>> However, EPICS device support (`devAsynUInt32Digital.c’) does not contain such a call.
>
> You are looking in the wrong place for that call.  That call is not part of device support, it is part of the
> asynUInt32Digital interface, and so is present here:
>
> <https://github.com/epics-modules/asyn/blob/a2f59505766f5a19af1afb325fc84b3a1d77552f/asyn/interfaces/asynUInt32Digital.h#L44>
>
>
> pasynUInt32Digital->setInterrupt() is used to configure the driver to control which bits will generate interrupts.
>
> It is implemented in the IPUnidig driver, for example:
>
> <https://github.com/epics-modules/ipUnidig/blob/990c5920e6a50f17b164db0477ccfdc28df97442/ipUnidigApp/src/drvIpUnidig.cpp#L543>
>
>
>> I’d expect, from the driver point of view, to be able to use `asynPortDriver::getInterruptUInt32Digital()’ to learn
> which bits records are interested in.
>
> No, it is the reverse.  Device support calls getInterruptUInt32Digital() to learn which bits the hardware has configured
> to generate interrupts.
>
>> • On read or write, `asynUInt32Digital’ passes the mask and the value to/from in the way appropriate for the device.
>
> Yes, that is true.
>
>>  For interrupts, `asynPortDriver’ will consider the mask given to `setUIntDigitalParam()’ and figure out which `IO
> Intr’ records to process based on both the mask and which bits in the value have changed.
>
> Yes, that is true.  But this has nothing to do with driver/hardware interrupts, which is what setInterruptUInt32Digital()
> is designed to control.
>
>> If the last point is true, then I guess `asynPortDriver::setInterruptUInt32Digital()’ really doesn’t seem useful for
> EPICS. I hope now you see why I’m wondering what it’s about
>
> You are mixing up software interrupts which are handled using callbacks for records with SCAN=I/O Intr with
> driver/hardware interrupts.  They are completely separate.  asynPortDriver::setInterruptUInt32Digital() only controls
> driver/hardware interrupts, which is why it is not used in many places.
>
> Mark
>
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Jure Varlec via Tech-talk <tech-talk at aps.anl.gov>
> Sent: Wednesday, January 26, 2022 2:32 AM
> To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> Subject: Use of asyn’s setInterruptUInt32Digital in EPICS device support
>
> Dear all,
>
> I’m looking at `asynPortDriver::setInterruptUInt32Digital()’ which is documented
> to be “called when asyn clients call `pasynUInt32Digital->setInterrupt()’”.
> However, EPICS device support (`devAsynUInt32Digital.c’) does not contain such a
> call.
>
> It’s not clear to me how this interface is meant to be used. I’d expect, from
> the driver point of view, to be able to use
> `asynPortDriver::getInterruptUInt32Digital()’ to learn which bits records are
> interested in. However, this does not work with EPICS, I don’t see how it could
> be set to logical-or of masks for all `IO Intr’ records, and I don’t see a use
> case for anything else. I don’t have a use case myself; I’m just wondering how
> the interface works and what it is meant for, presuming that it was implemented
> with some purpose in mind.
>
> Actually, I feel a bit unsure as to how the mask in the UInt32Digital interface
> really works. The documentation appears to be quite sparse on this topic. My
> understanding is the following:
>
> • `asynInt32’ deals with the mask in EPICS device support layer support while
>   `asynUInt32Digital’ delegates that to the driver.
> • On read or write, `asynUInt32Digital’ passes the mask and the value to/from
>   the driver unmodified. It’s up to the driver to apply the mask to the value
>   in the way appropriate for the device.
> • For interrupts, `asynPortDriver’ will consider the mask given to
>   `setUIntDigitalParam()’ and figure out which `IO Intr’ records to process
>   based on both the mask and which bits in the value have changed.
>
> If the last point is true, then I guess
> `asynPortDriver::setInterruptUInt32Digital()’ really doesn’t seem useful for
> EPICS. I hope now you see why I’m wondering what it’s about :)
>
> Best regards,
>
> Jure Varlec
> Senior Software Developer
> Cosylab d.d.
> www.cosylab.com

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System