EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  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 1994  1995  <19961997  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: rec/devSup advise needed
From: Andrew Johnson <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: [email protected]
Date: Thu, 22 Aug 1996 17:15:18 +0100 (GMT)
On Thu, 22 Aug 1996 08:08:02 -0500 Marty Kraimer <[email protected]> wrote:

> 2) Come up with a nicer syntax for hardware link specifications.
> For example instead of:
> 
>    #L0 A2 C0 S0 @whatever
> 
>    It would have been better to use something like
>     AB(0,2,0,0,"whatever")
> 
>    For camac it would be
> 
>     CAMAC(b,c,n,a,f,"whatever")
> 
>    where b,c,n,a,f are all integer values
> 
> At the present time it is difficult for dbStaticLib to determine
> the link type given the link specification. If we add more link types
> and use a syntax similar to that for existing links it may become
> impossible.

Would it be possible to create new versions of the link specifications 
now, as synonyms for the old ones, persuading people to start converting 
to the new format so the old stuff can be deleted in some later release?  
I even wondered about doing host-side conversion from the old to the new 
formats, but I guess that may be harder for some applications.

IMHO the new formats should not be hard-coded anywhere other than the 
drivers/device support which use them; the "link_type" in the database 
"device" definition should be something else which is definable in an 
ascii file (and convertable into a VME_IO.h file for example, which can be 
#included by the device/driver).  This way anyone could add a new address 
type without needing to rebuild base, but you should still be able to 
retain backwards compatibility for existing device/driver support.

$0.02

- Andrew

  O o ._    Andrew Johnson, Royal Greenwich Observatory
     __\\_	Madingley Road, Cambridge, CB3 0EZ
  __|ooooo|__	Tel +44 (0)1223 374823  Fax 374700
~~\_________/~~	WWW http://www.ast.cam.ac.uk/~anj/


Replies:
Re: rec/devSup advise needed Marty Kraimer
Re: rec/devSup advise needed Marty Kraimer

Navigate by Date:
Prev: Re: epics driver & device support for IP modules Jim B. Kowalkowski
Next: Re: rec/devSup advise needed Tim Mooney
Index: 1994  1995  <19961997  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: rec/devSup advise needed Ric Claus
Next: Re: rec/devSup advise needed Marty Kraimer
Index: 1994  1995  <19961997  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 ·