EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<19941995  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  Index <19941995  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 
<== Date ==> <== Thread ==>

Subject: Re: How to write driver support?
From: [email protected] (Bob Dalesio)
Date: Fri, 18 Nov 94 08:30:54 MST
There is the intention of standard ways to write device and driver support.

The driver layer encapsulates the VME board interface.
The device layer encapsulates the card specific stuff, as well as the
interface between the database and the driver.
For instance: the allen-bradley driver should contain all of the code
required to interface to the 6008sv.
The device layer should contain all of the information needed to configure
each card, convert raw analog to engineering units (and vice-versa), and
decode responses back from the driver for each specific card.
For VME cards, the device layer only handles the conversion to engineering
units. Not very efficient, but the solution was meant to be a generalization
that had to include all of the remote serial busses: GPIB, CAMAC, Allen-Bradley
etc...

We had originally dismissed the vxWorks calls as useless overhead. Since then,
we've added the device layer on VME cards.

The overhead was not measured as I remember.

The current implementation still has several problems with it:
definition of the base address
inclusion/exclusion of particular driver/devices on an IOC by IOC basis
proliferation of device types to handle variations of a particular card -
	vs. making the database definition more complicated
this issue of a "standard" interface

It is our intention to tackle these issues as part of version 4. It would be
helpful to this effort if you implement a driver using the ioctl approach
and benchmark it - and compare it to the direct approach.
It would also be useful if such numbers exist at DESY on the driver interface.
We may want to form a sub-group to address this. Thus far, Marty Kraimer,
John Winans, Jeff Hill and I have been working this issue. Marty and John
have put in the majority of the work. Anyone interested in an active role in
this (i.e. willing to put in more than their opinion) should contact one of
us and help with the design on the version 4 driver and device layers.

	Bob

Navigate by Date:
Prev: Re: WindC++ watson
Next: Re: WindC++ watson
Index: <19941995  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: How to write driver support? Nick Rees
Next: Lock sets for read access mcgehee
Index: <19941995  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, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·