Re: multi-channel analog i/p

[Peter Milne <peter.milne@d-tacq.com>]

Hi Stefen


On 24/06/15 08:32, Stefen Paul wrote:
> Hi,
>
> Is there a comprehensive document/website available telling about
> including 'driver support' in EPICS  ?
>
> How can one call vxWorks device driver routines from EPICS records and
> make the data read by driver routine available to the EPICS records ?
>
> Like in my case where I have a vxWorks driver for VME based 32-channel
> analog i/p board. I need to read the h/w through the driver only because
> of some FIFO design issues. But once the data is read by the driver, I
> would like to pass each channel's raw data to an individual ai record.

Something that works for me with a 96 channel digitizer:

- each AI record, scan ="I/O Intr", is registered with a custom device 
support.
- the device support starts a monitor thread that picks up an array of 
96 binary data values on interrupt.
- the monitor thread then causes each AI record to update by calling 
scanIoRequest().
- on update, the AI record simply picks the correct binary value from 
the array of 96.

The actual code is probably less relevant to you than the principle, but 
you'd welcome to read and use it:
http://www.d-tacq.com/swrel/acq2ioc.src.111108104002.tgz

We run this at 96 channels x 10Hz on a 400MHz cpu, the actual ADC sample 
rate is much higher of course ..

Cheers

Peter.
> Thanks,
> Stefen.
>
> On Tue, Jun 23, 2015 at 6:19 PM, Hartman, Steven M. <hartmansm@ornl.gov
> <mailto:hartmansm@ornl.gov>> wrote:
>
>
>     > On Jun 23, 2015, at 1:36 AM, Stephen Paul <stefen4114@gmail.com <mailto:stefen4114@gmail.com>> wrote:
>     >
>     > Instead , I first want a record and its device support to read all the channels from the board in one go and then pass these values to individual 32 ai records for conversion.
>     >
>     > Can anyone suggest what type of record I can use before ai record to achieve this ?
>
>     Rather then a record for reading all of the hardware values, your
>     device driver can have a worker thread responsible for reading from
>     the hardware. This can be scheduled either periodically or based on
>     some trigger. Your ai records would then read from the cached values
>     from this worker thread rather then directly from the hardware.
>     There are a number of drivers which take this approach, typically
>     with more complicated hardware with a large number of registers to
>     be read, or having a variety of different data types to support.
>
>     --
>     Steven Hartman
>     hartmansm@ornl.gov <mailto:hartmansm@ornl.gov>


--
Peter Milne
Director of Sales
www.d-tacq.com