Experimental Physics and
Industrial Control System

[email protected] (Bill Brown) · Mon, 11 Jul 94 11:42:35 PDT

Ned Arnold sez:
> How about having the driver allocate whether a byte is input or output
> depending on the first bit request for that octet. For example, if Bit 3 is
> specified in an input record (bi, mbbi), have the driver keep track that 
> bits 0 thru 7 are inputs. If an output record later requests bit 7, issue an
> error message that this cannot be accommodated. 

An interesting idea, altho assignment errors cannot be detected until
init-time.  I'll need to go look at the initialization process in detail
since I'm unsure exactly what gets tweaked at which time.

It seems like such a useful idea that it must violate some list of "Thou
Shall Not"'s or other.  (Sheeesh - it's so easy to be cynical on Mondays...)

John Winans adds:
> Lately, I have been writing drivers that require user configuration. 
> So many features and options that just can't be represented by the DTYP
> field alone.  I use a function that in your case would have a name
> like VmiVme2534Config().  It would take parms used to cinfigure the
> board.  For your situation, I would have the following parameters:
> 
> 1) The board link number to configure.
> 2) The board's base address is what ever address space it appears.
> 3) An IRQ vector and associated level.
> 4) A bitmask that describes the direction of data flow.

Hadn't thought about this approach.  Generally I like to try to avoid having
special invocations in the start-up file.

And then he adds:
> An alternate solution would be to leave the thing uninitalized and wait
> for the record init phase to decide what to do.  You COULD dynamically
> assign the data direction based on what the records are configured for.
> This is how the GPIB device support works with respect to knowing what
> devic addresses are used are attached to what links.
> 
> Ahhh... I now see Ned thinks highly of the dynamic config idea too.

And Marty Kraimer chimes in with:
> 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.

Yeah - I`m starting to think this may be the way to go for this particular
board.  We'll see what others have to add.

-bill

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System