Re: epics driver & device support for IP modules

["Jim B. Kowalkowski" <jbk@aps.anl.gov>]

Just a few comments on the HiDEOS IP support model -

The HiDEOS IP support library contains code called the IP manager that manipulates
the IP bus controller.  It also contains a database of make/model numbers for IP
modules it has knowns about (meaning that it knows how to start drivers for).
Each entry in the database looks like this:

  ManufacturerNumber, ModelNumber, DriverName, DriverCreateFunc, RamSizeIn64KbChunks

If the IP manager recognizes an IP module, it creates an IpModule class instance, then
instance knows how to manipulate a particular IP slot (interrupts/find registers/etc.).
The IP manager call the DriverCreateFunc with the ipModule instance and DriverName.
It is up to the DriverCreateFunc to do whatever it wants - with HiDEOS support IP
modules it starts up HiDEOS tasks - regardless if it is running under vxWorks or on
a stand-alone processor.  The DriverName is prepended with the slot number to for easy
identification from a record.  Each driver registers it's name in a table so users
(generally from EPICS device support) can search for the active IP modules and use
them.

This is all that there is to the HiDEOS IP support model - it is not that tightly coupled
with HiDEOS.  It does, however, require use of C++ to take advantage of all it's
features currently.

Matthias Clausen DESY -MKV2/KRYK- wrote:
> 
> >Hideos uses one "standard model" for supporting IP cards providing you
> >are using C++ and an MVME162
> 
> Some comments on Hideos:
> 
> If you use IP modules which directly handle analog and digutal signals like those used for
> the IRM you probably are better off using the direct access to the memory of the IP than
> using an indirect way through an intermediate system. This implies that a general solution
> has to take into account that there are different flavours of boards - some you directly
> access and some ( like serial communication boards) that are better handeled by a
> dedicated CPU to take care of all te asynchronous interrupts. In the latter field you are
> using packages like HIDEOS or CDI.

I have found that many of the ADC, in addition to the serial/GPIB type devices require
serialized access.  I have found it useful in several cases to actually have a 
driver task running that manages a multi-channel ADC.  

> An additional thought should be spent on the usage of drivers you provide for one ore the
> other package. You probably want to be able to run the same driver - and save development
> efford - regardless whether you run it on a dedicated CPU ( through HIDEOS or CDI) or on
> the same CPU. (which to the best of my knowledge is only possible with CDI)
> This design feature of CDI did help us a lot when we ported our CAN driver with the CAN IP
> to the PC hardware with the IP on a ISA /IP carrier board.

HiDEOS also runs on a single processor (68K based) under vxWorks. I haven't been advertising
this because I haven't had time to completely test all the IP drivers under vxWorks.

> 
> We should get some more input on this from other users of IP modules.
>  

I believe that people at Argonne will be using the HiDEOS method.  I have my a request
on my desk to complete to testing for the single processor (MVME162) system running
EPICS and HiDEOS under vxWorks.

> email with the people at fnal and learned the following:
> 
>  > If you look at the IP PROM contents using '162bug, you see the "IPAC"
>  > followed by mfg ID  (Fermilab's assigned Manufacturer ID is "$BB"), Model#,
>  > Rev#, three bytes of zero, the # of Bytes used ($14), and the CRC.   In the
>  > Module Specific space is "IRMIPDG6" for The digital IP.
>  [  ...  ]
>  > The Analog Interface IP is similar with the Module Space containing
>  > "IRMIPAN1".
> 
> It all seems to be as advertised.  On the other hand, you've actually done the
> work, so I'm probably overlooking something.  It's looks like vxWorks doesn't
> properly map the addresses of the IP ports, but I think that's a different
> problem.

Every IP module I have ever seem has make/model number in the IP PROM - it is
required in the IP spec.  It is not required to let vxWorks manipulate the IP
controller, I don't think I would trust them anyway - but that's just my opinion.
HiDEOS runs the chip itself, it is not that difficult to do.

> 
> >
> > Maybe we'll find some time during the next EPICS meeting to start the
> > discussion over coffee!?
> 

Unless I am missing something, this seems like a fairly straight forward problem to
solve.  The way I see it, you want a standard way to scan for and control IP modules and
IP bus slots.  This standard system will associate a name with an IP slot/module it
finds and optionally start a driver.  Users can use the system to find the IP module
by name and access it directly or through a running driver using a data structure
(or C++ class) given to them from the search function.

There are two libraries that I know about that currently work similar to this, the
VXI support library in EPICS and the HiDEOS IP manager support.

-- 
Jim Kowalkowski
708/252-9410
jbk@aps.anl.gov

Argonne National Laboratory
Advanced Photon Source - Accelerator Systems Division
Controls and Computing