Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Mon, 10 Sep 2007 17:21:45 -0500

Emmanuel,

> I am a little confused, and cannot find a clear way to define
> synchronous devices. Are PCI devices (ADC/DAC, frame grabber) all
> synchronous devices? I would think so, but after all maybe not...

According to the EPICS Application Developers Guide synchronous devices
those for which the processing can be done "without waiting".  This
obviously has room for interpretation, but a rule of thumb might be that
it takes no more than 1 msec or so to complete.  Not all PCI devices
will fall in this category.  Consider a frame grabber:  if this were
implemented using the asyn Int32Array or asynOctet interface, and the
driver implemented the "read" operation as trigger a frame, wait for
acquisition to complete, and return the data, this might take 1/30
second or longer.  This would definitely need to be asynchronous.
However, if the driver were constantly caching frames and just returned
the most recent one immediately, it could be synchronous.  Thus, what
model to use depends on how the driver is written.

> Not sure I understand. Are you saying that as long as I use supported
> asyn records, then I can use asyn?

No, I am saying that if your driver supports the standard interfaces and
you want to use the standard EPICS records, you will probably be able to
use the generic device support that is provided in asyn/devEpics.  You
don't need to write device support, you only need to write a driver.

>> - Your driver architecture will work when you port to a 
>> device that is asynchronous (or decide later it should be
asynchronous).
> 
> What would be the difference in the implementation? 
> For async devices, use callback, timed-out operations, 
> hardware/software interrupts.
> For sync devices, scan is set to a specific value. Is that it?

No, from the drivers point of view there is no difference in the
implementation.  The difference is that if the driver flags itself as
being asynchronous then asynManager will create a separate thread for
that device.  This means that EPICS record processing will not block
waiting for the device to complete its I/O, rather it will complete the
record processing when the I/O is complete.

> So if that is the case, because I intend to use asyn/software 
> interrupts does that make my driver asynchronous? And possibly I could
use a PCI
> card (frame grabber) as an asynchronous device...

You need to remember that the user controls how records are scanned.
Let's assume that your driver is written to support callbacks to device
support when there is new data.  That means that the user can put the
record in I/O Intr scan mode, and the driver will not wait for new data.
But what if the user puts the record in 1 Hz scan mode?  asyn will then
periodically issue read requests to the driver, and if they take a long
time to complete, your driver must have declared itself to be
asynchronous or EPICS will not work well.

Mark

> -----Original Message-----
> From: Emmanuel Mayssat [mailto:[email protected]] 
> Sent: Monday, September 10, 2007 4:24 PM
> To: Mark Rivers
> Cc: [email protected]
> Subject: RE: asyn for synchronous devices
> 
> Mark, all,
> 
> On Mon, 2007-09-10 at 15:04 -0500, Mark Rivers wrote:
> > If you make it
> > synchronous, then it will block other EPICS devices while it is
> > processing.  If the computation takes more than a msec or 
> so you should
> > make it asynchronous.
> 
> I am a little confused, and cannot find a clear way to define
> synchronous devices. Are PCI devices (ADC/DAC, frame grabber) all
> synchronous devices? I would think so, but after all maybe not...
> 
> > In general the advantage of asyn for synchronous devices is:
> > 
> > - You can use generic device support, no need to write specialized
> > device support.
> 
> Not sure I understand. Are you saying that as long as I use supported
> asyn records, then I can use asyn?
> 
> > - Your driver architecture will work when you port to a 
> device that is
> > asynchronous (or decide later it should be asynchronous).
> 
> What would be the difference in the implementation? 
> For async devices, use callback, timed-out operations, 
> hardware/software
> interrupts.
> For sync devices, scan is set to a specific value. Is that it?
> 
> So if that is the case, because I intend to use asyn/software 
> interrupts
> does that make my driver asynchronous? And possibly I could use a PCI
> card (frame grabber) as an asynchronous device...
> 
> > - You have well-defined interfaces between device support and your
> > driver.  The alternative is to create your own interfaces, with
> > associated debugging.
> 
> Does that mean that the way I want to use the asyn interfaces ( as
> described in an earlier email) is appropriate?
> 
> > I am not sure what you mean the "the upper asyn layer does 
> all of the
> > image processing".  Is this actually in an asyn port driver?
> I meant something like triggering the image processing in the asyn
> interrupt routine (for ex callInt32Interrupt), prior to the
> interruptStart call. 
> That way, the image is captured in the asyn interface and all the
> processing is done at a higher level (in the asyn interrupt). 
> 
> 
> Regards,
> 
> --
> E
> 
> 
> > > The design could be as follow:
> > > If I use a PCI frame grabber I instantiate the PCI interface.
> > > If I use a streaming server (AXIS), I instantiate the axis network
> > > interface.
> > > If I want a set of test images, I instantiate a dummy 
> interface, etc.
> > >  
> > > The upper asyn layer does all the image processing (such 
> as profile
> > > calculation, etc). The interface is actually the 
> "hardware driver" and
> > > its purpose is only the acquisition of a snapshot (in a 
> > > specific format)
> > > and the generation of software interrupts.
> > > 
> > > Is this a good design for asyn sync drivers?
> > > Should the profile calculation be part of the interface and the
> > > interrupt be generated when all the processing has been completed?
> > > 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System