Experimental Physics and
Industrial Control System

Benjamin Franksen via Tech-talk <[email protected]> · Tue, 9 Apr 2019 18:05:37 +0200

Hi Mark

I have been reading asyn documentation and code (including tests and
examples you pointed me to) for yet another day and it seems no matter
how hard I try I can't get my head around it. I guess that means it is
time to start writing my own IP driver and device support to use in
situations where streamDevice+asyn-as-is doesn't get the job done.

Cheers
Ben

Am 08.04.19 um 21:18 schrieb Mark Rivers:
> 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
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System