Experimental Physics and
Industrial Control System

[email protected] · Wed, 13 Jul 94 08:10:55 -0500

> 
> 
> 
> I want to do a little "thinking out loud" here .
> 
> You said:
> > The device init (NOT init_record) gets called twice at initialization time.
> > The second time is after all records have been initialized. As each record
> > calls the init_record entry of device support you could remember how each bit
> > is being referenced by the records (you get bitt offset and number of bits).
> > Then at the end configure the board. You can also look for conflicts and
> > generate errors.
> 
> This implies that the dev init routine has to know about some hardware
> stuff.  Well, maybe not.  Perhaps all that's needed is to add one entry
> point in the driver stuff that expects a board #, a byte #, and a direction
> (in or out) indicator to finally initialize the hardware.
> 

If you have a relatively simple device there is no need for a driver. You can
do everything in device support. A little history. Before epics there was
gtacs. The development of epics from gtacs took about a year. During this time
we wanted to keep drivers compatible between gtacs and epics the device
support layer was invented. That is why in many cases the device support layer
is very thin. Today I would keep drivers for things that yalk to many devices.
Examples are the allen bradley scanner, bitbus, gpib, etc.

In order to be able to produce hardware reports for dbior, a device (driver)
has to keep information about each device instance for which it is
responsible. Thus to implement what I am suggesting just means that it has to
keep track of more info.

By the way for epics 4.0 we are thinking seriously of having a device record
type for each device type and have the user create a device record instance
for each device instance. This will make it easy to provide device
configuration information. In the meantime there is a problem. The old way was
to put definitions in module_types.h. This means each site(or even user) ends
up having a private version of module_types.h. Another thing you can do for
now is what you suggest. Have an extra global routine (devXXXConfig or
something like that) that can be executed before iocInit. This is a way to
specify things like vme address, interrupt vector, etc. For configuring
indivdual signals, I still like my initial suggestion.

> But, since ioScan needs to know inputs from outputs, the logical place for
> the direction information is in the driver control structures.  devSupport
> needs an entry point in the driver to call to get the address of the 
> structures so it can use them during dev_Init.  But it really doesn't need
> to know about the structure; all it needs is a pointer to the location
> that has the direction information about the specified i/o board.
> 
> One more question - is there any defined limit on the size of a mbb[io]
> PV?  Since it seems like they may overlap byte boundries, this could get
> tricky.  The only _real_ problem I see the slight time-offset in the output/
> input values which could result if the mbb[io] PV spans byte boundaries.

Not really. NOBT determines the number of bits and normally the signal number
determines the bit offset. This is pretty general. The only real limitation is
the the state mask fields are 32 bit integers.

Marty Kraimer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System