Greetings,
Comments for 'HARDWERE RECORD' an other wiew:
1) The current Epics database structure is a nice mapping of the
induvidule points into 'records' .
2) There is no mapping of the hardware configuration , what
was existing: module_types.h
The problem what we try to solve:
=================================
- a new (optional) mapping of the IOC hardware (e.g VME or PCI bus)
configuration
* This is the minimum for handling a various hardware
configuration and useing one compiled Epics IOC.
* A part of it must be know only the 'driver' -
(e.g. VME address space, int. vector)
an other part must be known by the 'channel'
records (e.g. RAWH,RAWL or MASK for BI/BO)
- make the 'hardware' dependent parameters visible and
(for the future) runtime configurable.
- adding spaceholder for the prototype modules which are
connected via (e.g. ) field bus to the IOC. (e.g. CAN
moduls )
* One way (see the mail from Ralph BESSY) mapping
each induvidual module for an object in IOC
* Or useing a 'prototype' object - which only
a spaceholder of the 'type'
- handle and support a more configurable devices such as
BE490 adc.
* this device can handle ap to 8 channel, has
27 configurable general parameters and 16
configurable parameter / channel (!)
An approach for the last item. (This is under construction !)
1. The hardwere will be mapped as a record
2. The record (BE490) will be new, which contains
the all 27 + 8 * 16 parameter field. (This is a spaceholder
function)
3. At the record initiate time will be the hardwere initiated
* By the way, how can I force the iocInit to initiate this
record before the ai recrds pointing this device will be
initiated ?
* At the initiate time the record try to get the static
information (such as IO address space Interrupt level,
and when it is faild - usese the (DCT) configured
parameters.
4. The record has 8 'LINK' pointing the correspondent ai
records.
Which answere can be added useing hardware record ?
1. The proposed hardware record covers the past and
not the future requiroments.
That is meaning it is nicely fitted an existing hardwares
but does not cover the problem of the 'filed bus' modules,
and does not cover the intelligent devices.
2. The configurable parameters are visiable (dct)
and CA.
3. There are the possible run time reconfiguration
useing the existing (CA/dbAccess) mechanism.
I hardly supported the hardware record with the following
requiroments.
The all 'hardware record' must be initiated eralier than
the connected 'channel' records and earlier then the dev/drv
which is connected to this one.
With other words, I prefer the following sequence:
1. The hw record applies his 'global' parameters -
if it does not success - uses his configured ones.
2. and make a registration to reserve them. (Don't forget,
maybe some resource has been allocated before Epics was
downloded)
3. the device/driver support module gets the parameters from
the hw record and makes the initialisations work.
4. When all 'hw' record initiation has been finished:
can start the 'rest'.
I don't think so that we can cover the all problems
useing a common 'hardware record' but it is high time
to start this work.
Gabor Csuke
DESY, Germany
- Replies:
- Re: Hardware Configuration watson
- Navigate by Date:
- Prev:
alarm-handling questions William Lupton
- Next:
RTYP ? Pete Jemian
- Index:
1994
1995
<1996>
1997
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: Hardware Configuration Ralph Lange
- Next:
Re: Hardware Configuration watson
- Index:
1994
1995
<1996>
1997
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
|