Re: EPICS device support questions

[Carl Lionberger <CALionberger@lbl.gov>]

Although the concept of directly calling API functions from EPICS sounds 
very clean I know of no way of handling the parameterization properly. 
Two approaches I might use are:

1.  Use subroutine (ie, "sub") or genSub records.  In this case you 
would have to write a  C function that maps the API function parameters 
into the subroutine record parameter fields and reads or writes those 
fields as appropriate when the record processes. This way you could 
still reasonably approximate the API functional layout.

2. Write custom device supports for whatever record types seem 
appropriate, using the API at the next level down, corresponding to 
driver support.  In the case of complex devices this leads to a suite of 
device supports.  In the case of an oscilloscope, I would use ao records 
for many of the controls, waveform records for reading the traces, mbbo 
for selecting triggering modes, and so forth. This method can achieve a 
high level of integration between device and EPICS functionalities.

Carl

Gabriel L. Rael wrote:

> 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


--
Carl Lionberger 
510 486 7503
Software Developer, Engineering Division
Lawrence Berkeley National Laboratory