Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Tue, 4 Sep 2007 20:50:35 -0500

I second the call to use asyn.  Here is the architecture I would suggest from the top down.

1) Use the standard EPICS device support that is provided in asyn.  This supports most of the common EPICS record types.
2) Write an asyn driver that implements the interfaces that make sense for your device (asynInt32, asynFloat64, asynInt32Array, etc.).
3) Your asyn driver then calls your existing drivers.  If it is an asynchronous device, asyn has already taken care of running your code in its own thread.

If you have functions that take multiple arguments you could use one PV per argument, and either cache the values and write them all at once when one "special" one is written, or send them all each time any one is written.

This is the model I have used for a large number of devices that have manufacturer supplied drivers or libraries.

Mark

________________________________

From: [email protected] on behalf of Eric Norum
Sent: Tue 9/4/2007 6:44 PM
To: Chestnut, Ronald P.
Cc: [email protected]
Subject: Re: EPICS device support questions

On Sep 4, 2007, at 6:26 PM, Chestnut, Ronald P. wrote:

> Dear Gabriel,
>
> You are asking about doing this in a very clean way, which one can 
> only strongly encourage.
>
> We have done some interfacing to high-speed RF Analog and Digital 
> equipment using a USB interface. The FPGA in the equipment uses a 
> set of registers to communicate, and on the EPICS side, we use a 
> set of canned USB-calling subroutines. The division of labor lets 
> non-EPICS engineers get the Linux and FPGA sides of the USB calls 
> working, then we use subroutine records in EPICS to call the 
> engineer-certified routines.
>
> One interesting feature needed for work with EPICS was some 
> semaphores to keep the USB calls single-threaded, since the FPGA 
> side can deal with only one request at a time.

At this point I'd like to put in my obligatory plug for ASYN which 
does the locking and multi-threading for you.  ASYN also provides 
mechanisms for producing diagnostic/debugging messages along with 
records and MEDM screens for controlling them.  This unified method 
of producing and controlling driver trace/debug/diagnostic messages 
makes ASYN useful for synchronous register-based devices as well as 
asynchronous message-based devices.  ASYN can also decouple drivers 
from records so the same support can be used with different record 
types.

Maybe Marty Kraimer, Mark Rivers or others can add their own 
testimonials here for why ASYN is a good framework for writing 
drivers.....

>
> This is not as pure or clean as a good device-oriented 
> implementation, but it does work - we have three different devices 
> in service this way.
>
> Ron Chestnut
>
> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of Gabriel L. Rael
> Sent: Tuesday, September 04, 2007 3:59 PM
> To: [email protected]
> Subject: EPICS device support questions
>
> Hello, all.
>
> We are in the process of creating an EPICS interface to our 
> oscilloscope.  It is a PCI device with its own kernel driver and 
> user space driver with the host processor that will be running our 
> EPICS IOC.
>
> It seems that though EPICS supports a list of communication 
> interfaces (GPIB, VME, VXI, serial, etc.), it does not allow for a 
> device to be connected above this layer through an ANSI-C API 
> easily.  Though asyn device support is a complete solution down to 
> the kernel level, we want to be able to leverage our existing drivers.
>
> For packaging up this functionality, we want to create records that 
> map directly to our API calls, which are functions with variable 
> arguments, some that may be passed by reference for modification.  
> We have function tables containing our calls with variable argument 
> types, but we are not seeing a common way to link PVs to function 
> calls with arguments.  In the dbd, we are doing something like:  
> device(ao, INST_IO, devScopeao, "scopeAPI").  Can I use the INP and 
> OUT fields arbitrarily, parsing a common syntax (i.e. a single 
> string value such as "@function arg1 arg2") in the device support 
> layer, to make function wrappers?  Is there a general way that we 
> can hook into something that already accomplishes this?  Does this 
> break the ability to link PVs properly?  Can I do this using the 
> standard record types?  Am I missing something else?
>
> Thanks in advance!
>
> -glr
>
> --
> Gabriel L. Rael
> Jr. Software Engineer
> ZTEC Instruments
> http://www.ztecinstruments.com <http://www.ztecinstruments.com/> 
>
>

--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System