RE: Analog output device support design

["Mark Rivers" <rivers@cars.uchicago.edu>]

I'd second Erics suggestion about writing an asyn driver, rather than writing device support.  The standard asyn device support already takes care of the complexities of handling I/O Intr scanning, etc.  For an ai device it has support for averaging, i.e. your driver is calling back with new values at 1 kHz, but the device support can average all the readings between record processing at the standard periodic scan rates.  
 
By writing an asyn driver you free the developer to use whatever records they chose; perhaps the standard ai record, but they could also use the mca record to put the callback values into a time-series array, or use the epid record to do fast feedback at the 1kHz callback rate from your driver, etc.  That support is already written.
 
Mark
 

________________________________

From: tech-talk-bounces@aps.anl.gov on behalf of Eric Norum
Sent: Mon 7/26/2010 6:15 PM
To: Angus Gratton
Cc: EPICS tech-talk
Subject: Re: Analog output device support design



On Jul 26, 2010, at 4:00 PM, Angus Gratton wrote:
......
> Yes, I understand. I've been working from the well documented minimal
> example given in this presentation:
>
> http://www.aps.anl.gov/epics/meetings/2009-07/talks/em_WritingEPICSDrivers.ppt

That's a good set of instructions.  
If you need asynchronous device support I would suggest that you look through the ASYN support module documentation.
In fact I'd go so far as to recommend ASYN for VME register-based synchronous access as well.  The 'devEpics' support provides a good way to decouple your I/O support from particular record types.  The synApps package contains the ASYN support module and lots of good drivers (e.g. ip330) for existing VME hardware.   One of these might be a good place to start modifying to match your hardware.

>
> Outside of there, I've downloaded a few device support sources and
> looked at them but to be honest it's hard to tell what is legacy and
> what is a good example - lots of the sources haven't been touched in
> many years, some of them do things like combine device support & the
> driver into the same source, which I understand is no longer
> recommended. Which is why I thought I'd ask to be sure, because I'm not
> yet experienced enough to tell the difference between a good example and
> a bad one.
>
> Regards,
>
> Angus
>

--
Eric Norum
eric@norum.ca