Experimental Physics and Industrial Control System
|
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]
- Replies:
- RE: Analog output device support design Mark Rivers
- References:
- Analog output device support design Angus Gratton
- Re: Analog output device support design Ralph Lange
- Re: Analog output device support design Angus Gratton
- Re: Analog output device support design Eric Norum
- RE: Analog output device support design Mark Rivers
- Navigate by Date:
- Prev:
Re: Analog output device support design Ralph Lange
- Next:
HTML Device Driver David Dudley
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Analog output device support design Mark Rivers
- Next:
RE: Analog output device support design Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|