Experimental Physics and
Industrial Control System

"Chestnut, Ronald P." <[email protected]> · Tue, 4 Sep 2007 16:26:08 -0700

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.

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:[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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System