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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Use of asyn's setInterruptUInt32Digital in EPICS device support |
From: | Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> |
To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>, Jure Varlec <jure.varlec at cosylab.com> |
Date: | Wed, 26 Jan 2022 14:48:04 +0000 |
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:
pasynUInt32Digital->setInterrupt() is used to configure the driver to control which bits will generate interrupts.
It is implemented in the IPUnidig driver, for example:
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 |