Experimental Physics and
Industrial Control System

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

Excellent, thank you so much for the explanation!

Best regards,

Jure

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

> Ø  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?
>
>
>
> That is correct.  A common example of a software event is the driver polling the hardware, and doing the callbacks to
> process the EPICS records when the value changes.
>
>
>
> 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.
>
>
>
> That is correct.
>
>
>
> Ø  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?
>
>
>
> That is an excellent point.  In fact, there is currently no way to call the setInterruptUInt32Digital method in the
> IPUnidig driver from EPICS records.  The configuration of the hardware interrupts is done in the constructor using the
> risingMask and fallingMask variables passed to  initIPUnidig from the startup script, and there is currently no way to
> change them at run-time.
>
>
>
> If there is a need to configure the interrupts for that then there are 2 possible solutions:
>
> -          devAsynUInt32Digital.c could be changed to support calling the setInterrupt and clearInterrupt methods in the
> asynUInt32Digital interface.  One would need to establish a convention of the value of  the drvUser field in the record
> link field that means this is an interrupt mask, not a data value.
>
> -          A simpler solution for the IpUnidig would be to extend the drvUser fields it supports.  Currently these are:
>
>
>
> #define digitalInputString  “DIGITAL_INPUT”
>
> #define digitalOutputString “DIGITAL_OUTPUT”
>
> #define DACOutputString     “DAC_OUTPUT”
>
>
>
> One could add:
>
> #define risingMaskString  “RISING_MASK”
>
> #define fallingMaskString  “FALLING_MASK”
>
>
>
> and add these to the parameter library.
>
>
>
> The driver’s writeUInt32Digital method would then check the pasynUser->reason, and if it is one of these values then
> it would call the setInterruptUInt32Digital method internally.
>
>
>
> Mark
>
>
>
>
>
>
>
> —–Original Message—–
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Jure Varlec via Tech-talk
> Sent: Thursday, January 27, 2022 1:48 AM
> To: tech-talk at aps.anl.gov
> Subject: Re: Use of asyn’s setInterruptUInt32Digital in EPICS device support
>
>
>
> 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/a2f59505766f5a19af1afb325f>
>
>> c84b3a1d77552f/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/990c5920e6a50f17b164db>
>
>> 0477ccfdc28df97442/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