RE: drvAsynIPPortConfigure and I/O Intr with asynRecord possible?

[Mark Rivers via Tech-talk <tech-talk@aps.anl.gov>]

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 <benjamin.franksen@helmholtz-berlin.de> 
Sent: Monday, April 8, 2019 12:52 PM
To: Mark Rivers <rivers@cars.uchicago.edu>
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