EPICS Home

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: epics driver & device support for IP modules
From: "Jim B. Kowalkowski" <[email protected]>
To: [email protected]
Date: Thu, 22 Aug 1996 11:08:55 -0500
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
[email protected]

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


References:
Re: epics driver & device support for IP modules Matthias Clausen DESY -MKV2/KRYK-

Navigate by Date:
Prev: Re: epics driver & device support for IP modules Matthias Clausen DESY -MKV2/KRYK-
Next: Re: rec/devSup advise needed Andrew Johnson
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: epics driver & device support for IP modules Matthias Clausen DESY -MKV2/KRYK-
Next: Re: epics driver & device support for IP modules 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