Folks,
I have found a problem in the APIs used by device support to receive
callbacks from asynDrivers. These are the callbacks that an asyn driver
supports via pasynManager->registerInterruptSource, and device support
accesses via, for example, pasynInt32->registerInterruptUser. These
callbacks allow EPICS records to have "I/O Intr" record processing, i.e.
the record only gets processed when the driver calls back device support
with "new" data.
The problem is that there is no status information passed back to device
support in the callback. This means that if the driver detects an
error, there is currently no way for it to notify device support that
there is a problem, so that the record can set its Status and Severity.
This is not a problem for EPICS records that are not using callbacks
(i.e. not I/O Intr scanning), because when they call, for example,
pasynInt32->read(), they receive a status return which allows them to
set Status and Severity.
This problem has not really arisen before now, because the drivers that
used callbacks were typically VME devices, which either failed at
initialization, or "always worked". However, I now want to use
callbacks for Modbus TCP, which can definitely switch from working to
not working when the network connection is lost. We want EPICS records
to display a problem when this happens.
I think the cleanest way to fix this problem is to add an additional
status parameter to the callbacks. Drivers will be responsible for
calling device support at least once when the status changes, even if
there is not "new data". This change will require rewriting drivers and
device support that use such callbacks. I suspect most people who are
using callbacks are using the generic device support which is part of
asyn, which I will change. I will also, of course change the drivers I
support.
For the asynInt32 interface, for example, I would change:
typedef void (*interruptCallbackInt32)(void *userPvt, asynUser
*pasynUser,
epicsInt32 data);
to
typedef void (*interruptCallbackInt32)(void *userPvt, asynUser
*pasynUser,
epicsInt32 data, asynStatus
status);
However, before I do this, I want to see how many other people have
written asyn drivers or device support that uses such callbacks, and
whether they agree with the proposed change. If so, this will be
included in the next (R4-8) release of asyn.
Mark
- Replies:
- Re: Proposed change in asyn interruptCallback APIs Andrew Johnson
- References:
- ASYN-4.7 Eric Norum
- Navigate by Date:
- Prev:
Re: WireSet & mpc8540 Ernest L. Williams Jr.
- Next:
Re: .cmd file downloading problem Kate Feng
- 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
- Navigate by Thread:
- Prev:
ASYN-4.7 Eric Norum
- Next:
Re: Proposed change in asyn interruptCallback APIs Andrew Johnson
- 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
|