RE: ai/ao RAWL RAWH

[csuka@desy.de (Gabor Csuka)]

Dear All,

After 10 comments, I try to make mine:

There is one general question - the place of the device 
dependent parameter(s)  part (if any is needed) and the
driver configuration / reconfiguration etc. But this is
a thema for a workshop.  


A record has a common part which is same for each record
and a record specific type. In each part can be a device
dependent part. This moment the existing field is DTYP,
DPVT (in common) and as an example ESLO, ROFF, INP/OUT for ai/ao.
and MASK field for bi/bo.

This is also clear, it is not possible get the all configuration
parameter from the hardware (as the suggestion of Jimm) while
not the all hardwere has this functionality. (e.g. CAN,h1,
profibus moduls has no this functionality.)  From this
it is clean this information can be hardcoded in the device 
support module, or getting as a parameter. From the example
below both of them is used yet. (Alen Braedly has separate
device support, Can, (all of three implementation) H1,
atc. ) useing 'encrypted' INP/OUT specification :


<Bus name>/<Timeout>:<Can Identifier>.<offset> <misc parm>
INP  #C2 V"2-DI0-0..15" M"can" N300 I0 W2 L0 H4095
  

Other VME cards using the PARM field of VME IO adding this
dinamic information.

> parm strings of the form "TERM=0d0a,IX=3,FMT=%lf,TO=300,..." to

so the information is there. The question is: the RAWH and RAWL 
is enough common device specific for adding ai/ao (and getting
nice support for this fields) or keep them 'encrypted' and
hidden. 

Go back to the INP/OUT specification. See the DESY CAN:
 
INP  #C2 V"2-DI0-0..15" M"wm_ai" N300 I0 W2 L0 H4095
       |       |           |       |   |  |  |    |
       |       |           |       |   |  |  |    +-  raw value high
       |       |           |       |   |  |  +------  raw value low
       |       |           |       |   |  +---------  data type and length
       |       |           |       |   +------------  offset/index
       |       |           |       +----------------  CAN ID
       |       |           +------------------------  Can module name 
       |       +------------------------------------  Variable name
       +--------------------------------------------  CAN controller ID

{ general IO point description             }{ ai/ao specific }

this description has (and need) two parts , the general one
and the record type dependent one. Why I keep them in one field ?

If the specific one is INDEPENDENT from the device why 
the device dependent part makes the support for it ? 

This moment we on the way to adding separate support 
in each inteligent 'devise' (useing separate device support
roitine per module, or useing encrypted string and analise
it in devise support at init time ? ) 

My suggestion adding this two field to ao/ai is a way 
to start some generic solution instead of learning 
hundreds of 'encrypted' syntax. 

Regards, 

Gabor Csuka
DESY