Experimental Physics and
Industrial Control System

Ralph Lange <[email protected]> · Wed, 28 Jul 2010 11:09:26 -0400

 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: [email protected] 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
[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System