Re: EPICS device support questions

[Eric Norum <norume@aps.anl.gov>]

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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk- 
> bounces@aps.anl.gov] On Behalf Of Gabriel L. Rael
> Sent: Tuesday, September 04, 2007 3:59 PM
> To: tech-talk@aps.anl.gov
> 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

--
Eric Norum <norume@aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793