Re: Analog output device support design

[Ralph Lange <Ralph.Lange@bessy.de>]

 Hmm...

The original question was about support for an D/A converter.

A D/A converter will hardly ever need support for anything else but an 
ao record.
As a VME based memory-mapped device, it typically does not need 
asynchronous support, and does not implement I/O Intr scanning.
It uses a fixed bit width, which is unlikely to change.

While Asyn is a very generic and powerful framework, in this case it 
does not provide much added value, while requiring a lot of reading and 
understanding of mechanisms and interfaces that are not applicable.

So I would repeat my suggestion of taking an existing Device Support 
module for another VME D/A card, and change the bits where your hardware 
is different.
Only having Device Support is perfectly appropriate in this case, as 
there is no "bus" type connection (such as GPIB, serial etc.) that would 
justify separating the driver for that bus from the driver for the 
device you are talking to.

Device Support for a VME based D/A converters is usually very simple, 
and with a simple "steal-and-adapt" approach you should be up and 
running in a very short time.

For supporting A/D converters, Mark's arguments are many and strong: 
clearly a case for Asyn.
(But I would save that for a moment when you are more experienced and 
more adventurous, and using Asyn has strong advantages.)

Just my 2 cents...
Ralph


On 26.07.2010 22:42, Mark Rivers wrote:
> 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