Experimental Physics and
Industrial Control System

[email protected] · Fri, 13 Dec 1996 17:47:54 -0500 (EST)

Jim,

On Fri, 13 Dec 1996 07:58:20 -0600 "Jim B. Kowalkowski" <[email protected]> 
wrote:

> I see three basic IP developments in process, maybe four:
>  1) telescope community (Andrew/Peregrine)
>  2) IRM developments and other (Matthias/DESY/Fermilab)
>  3) HiDEOS
4) Kay-Uwe Kasemir's driver, which is PC-aware.

> My main question is this: What is the main reason that you (supporters and
> users of 1 and 2) have dismissed HiDEOS?  Much (not all) of the development
> in 1 and 2 has been done after the HiDEOS development.  I'm really not trying
> to sell HiDEOS or anything, I just want feedback.

I'll try and list as many reasons as I can think of.
1. The HiDEOS IP software will only work on an mv162 CPU, or (with some 
changes) on a carrier board based around the IPIC chip.  I had a long look 
at the source-code for the HiDEOS driver before concluding that we 
couldn't use it.  The GreenSpring VIPC-310 and -610 IP carriers which I 
had to support are *totally* dumb; you can only change the interrupt 
levels by blowing a new PAL, and the base addresses are set by jumpers. 
Neither setting can be discovered by reading a register, because there are 
no registers.  Autoconfiguration of the carrier boards is thus impossible 
-- if you don't have an IP module installed you can't tell whether there's 
a carrier board there or not.  I forget if your software provide a means 
of manual configuration or not, but you certainly need it to support the 
GreenSpring carriers.  The carrier driver software would also have to 
provide a way of telling a module driver "sorry, you can't do that with 
this carrier" and I couldn't see how with your current interface.

2. We needed to be able to install multiple carrier boards simultaneously, 
and we might have needed to be able to add a GreenSpring card to a system 
that was already using the mv162, hence loading two different carrier 
drivers.

3. Yes, C++.  I agree it's the way things are moving, but we would have 
had to jump through some hoops to get Gemini (the customer) to agree to 
our using it.  I also failed to build the g++ cross-compiler, which didn't 
do much for my confidence in the approach.

4. We found it difficult to justify loading what seemed a non-trivial 
amount of HiDEOS software on top of EPICS just to be able to communicate 
to one type of IP module (a similar reason for our rejection of CDI BTW).

> I think it would be nice if we could have a unified IP support package

I think it is crazy *not* to have a unified IP support package, but IMO 
there wasn't anything suitable before I wrote drvIpac.  I'm willing to 
modify my CANbus driver to run under anything that we decide upon as a 
standard, provided it supports the GreenSpring boards sensibly.  I suspect 
that drvIpac is the most general-purpose of all the IP support packages, 
but I'm not saying we *have* to use it.

- Andrew
   ___
 .'   `.        Andrew Johnson, Head of Electronics
/ Royal )       Royal Greenwich Observatory
\ Greenwich     Madingley Road, Cambridge, CB3 0EZ
| Observatory   Tel: +44 1223 374823   Fax: 374700
+----------     WWW: http://www.ast.cam.ac.uk/~anj

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System