Re: CAMAC

[mrk@aps.anl.gov (Marty Kraimer)]

> From dalesio@luke.atdiv.lanl.gov Fri Nov  4 02:09 CST 1994
> Date: Fri, 4 Nov 94 01:09:00 MST
> From: dalesio@luke.atdiv.lanl.gov (Bob Dalesio)
> To: tech-talk@aps.anl.gov
> Subject: CAMAC
> Content-Type> : > text> 
> Content-Length: 425
> 
> There are currently two schools of thought on the addressing of cAMAC.
> One puts the configuration parameters into a proliferation of DTYPs
> The other overloads the param field.
> Is there a way to install the driver that either will work?

My guess is that either method relys on a thin device layer above the actual
camac driver. If you are talking about the CEBAF driver I am sure this is true.
The CAMAC driver has no knowledge of EPICS (nor should it) but relys on a
device layer to interface to epics. This both methods could easily be supported.

> Should we standardizer on one or the other?

I vote for overloading the parm field.

> Should we be tolerant until version 4 comes along and fiexs this problem?

I vote yes.

> In the mean time which should be intsalled to demonstrate CAMAC.

I think I already gave my opion above.

One last comment. This concerns configuration parameters for the driver such
as vme addresses. PLEASE dont add any more definitions to module_types.h.
Instead provide a configuration routine that can be executed from the 
vxWorks startup file. For example

camacConfig(<vme addr>,<interrup vector>, ... )

Also use the device registration routines described in the application
developers guide to allocate vme addresses, interrupt vectors, etc.

We can do better in Version 4 but for now this is the best "band-aid" I can
think of.

For Version 4 we can do better

Marty Kraimer