Experimental Physics and
Industrial Control System

Benjamin Franksen via Tech-talk <[email protected]> · Mon, 8 Apr 2019 20:13:12 +0200

[sorry for possible duplicate, forgot to add the list to my reply]

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