EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20192020  2021  2022  2023  2024  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  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: drvAsynIPPortConfigure and I/O Intr with asynRecord possible?
From: Mark Rivers via Tech-talk <[email protected]>
To: 'Benjamin Franksen' <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Mon, 8 Apr 2019 19:18:36 +0000
There are lots of examples of drivers that do callbacks on the asynOctet interface to stringIn records that have SCAN=I/O Intr.  devAsynOctet supports this, and lots of areaDetector drivers use it.  There are lots of simple examples in asyn/testEpicsApp, testErrorsApp, etc.

Record and device support does not expect that it needs to do a read() operation to generate the callback.  The driver itself should do the callback when there is new data.

It seems like you should be able to write a layer that calls (indirectly) pasynOctetBase->read(), and if clients have registered for asynOctet callbacks they will be called because that read function calls callInterruptUsers().

Mark


-----Original Message-----
From: Benjamin Franksen <[email protected]> 
Sent: Monday, April 8, 2019 12:52 PM
To: Mark Rivers <[email protected]>
Subject: Re: drvAsynIPPortConfigure and I/O Intr with asynRecord possible?

Hi Mark

thanks a lot. As you can see from my other reply I had come to the same conclusion wrt pasynOctetBase->initialize().

Am 08.04.19 um 18:56 schrieb Mark Rivers:
> [...]
> So the drvAsynIPPort driver does explicitly ask for
> pasynManager->registerInterruptUser() to be called on the asynOctet
> interface.
Yup.

> Marty wrote this code a long time ago, and I'm not sure why he added 
> the call to pasynManager->registerInterruptUser for the asynOctet 
> interface initialization, but not for the other interfaces.> [...]
> 
> Note that the final argument is only set to 1 for the drvAsynSerialPort, drvAsynSerialPortWin32, drvAsynIPPort, and optionally for asynStandardInterfacesBase.
> 
> 
> 
> Note that asynOctetBase.c also implements a convenience function called callInterruptUser() to actually do the interrupt callbacks.  This is the locations in asyn itself where that function is called:
> 
> 
> 
> corvette:~/devel/asyn>find . -name '*.c*' -exec grep -H 
> callInterruptUsers {} \;
> 
> ./testApp/src/addrChangeDriver.c:    pasynOctetBase->callInterruptUsers(pasynUser,paddrChangePvt->pasynPvt,
> 
> ./testApp/src/echoDriver.c:    pasynOctetBase->callInterruptUsers(pasynUser,pechoPvt->pasynPvt,
> 
> ./asyn/asynGpib/asynGpib.c:    pasynOctetBase->callInterruptUsers(pasynUser,pgpibPvt->pasynPvt,
> 
> 
> 
> Note that the drvAsynSerialPort and drvAsynIPPort drivers do not call it.  So I am not sure why the interruptProcess flag is set to 1 in those drivers calls to pasynOctetBase->initialize(), since they never actually do interrupt callbacks.
> 
> 
> 
> But if you want to try to implement interrupt callbacks in drvAsynIPPort, then most of the groundwork is already done.  You just need to call pasynOctetBase->callInterruptUsers().

I don't think this will work. pasynOctetBase->callInterruptUsers() is already called by the read method of asynOctetBase. I don't know why it was done that way but it means I cannot use the existing support for interrupts in asynOctetBase as that would cause the record(s) to process in an endless loop. Instead I think I will have to add yet another flag to drvAsynIPPortConfigure that disables the existing interrupt support in asynOctetBase (passing 0 as the last argument of
pasynOctetBase->initialize()).

However, having done that I found that things still do not work as I expected, notably, it looks as if the asynRecord does /not/ issue a read request if its SCAN field is set to IO Intr. This explains why the record gets processed endlessly in my test. (If no read is done in response to the processing, then the poll status isn't reset and the record gets processed again and again.)

I am not sure how I am supposed to fix that. I can't read inside the driver's poll loop, because the driver doesn't know how many bytes it should read and anyway how to pass the result to the record(s). I guess there is something in the way interrupt processing is designed in asyn that I am still failing to understand.

Cheers
Ben


Replies:
Re: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Dirk Zimoch via Tech-talk
Re: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Benjamin Franksen via Tech-talk
References:
drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Christoph Schroeder via Tech-talk
Re: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Mark Rivers via Tech-talk
RE: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Mark Rivers via Tech-talk
Re: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Benjamin Franksen via Tech-talk
RE: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Mark Rivers via Tech-talk
RE: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Mark Rivers via Tech-talk
RE: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Mark Rivers via Tech-talk

Navigate by Date:
Prev: RE: asynMotor device support and the motor specific driver (asynMotorContorller) Mark Rivers via Tech-talk
Next: Re: asynMotor device support and the motor specific driver (asynMotorContorller) Allan Serra Braga Bugyi via Tech-talk
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  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Benjamin Franksen via Tech-talk
Next: Re: drvAsynIPPortConfigure and I/O Intr with asynRecord possible? Dirk Zimoch via Tech-talk
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  <20192020  2021  2022  2023  2024 
ANJ, 09 Apr 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·