Lines Matching refs:hardware

45 The Parameter Framework aims to be a hardware control abstraction layer.
48  1) hardware api abstraction
49  2) hardware parameter abstraction
50  3) high level hardware independent abstraction
52 The fundamental constraint on the underlined hardware is to be representable
58 Each abstracted hardware usualy have different apis, this layer responsibility
66 the hardware parameter properties (domain of validity, size, human representation...).
70 ### High level hardware independent abstraction
71 The goal of this layer is to abstract the hardware parameters behind abstract parameters
74 This is done by linking those abstract parameters and the hardware parameters with
107  - historically the PF reference implementation was used to abstract hardware
110 (FIXME: choose "subsystem" instead of "hardware" ?)
116 <why>because the PF aims to abstract hardware and model it by parameters.</why>
121 <why>because a parameter without value would not abstract any hardware.</why>
125 <why>To control the underlined hardware.</why>
133 <why>To dump all parameter value, debug a hardware state,
134 save parameters values, display the current hardware state,
290  - scales the user value to the hardware value (client => syncer)
291  - converts the hardware value to the user's value space. (syncer => client)
301 Parameters exposed by hardware sometimes need to be normalized.
302 <note>For example a hardware integer parameter could have a range 64-128 but it might
306 <note>For example the hardware could expose a parameter in cm but it might better
362 The PF philosophy is to map the hardware characteristics to parameters.
363 In order to impact the hardware when parameters are modified, a hardware specific
366 Syncers are responsible for synchronizing the values of parameters to the underlined hardware.
367 Ie, it is the glue between hardware and parameters. It contains the code specific
368 to access an hardware.
370 The aim of the PF is to keep this hardware specific code as light as possible.
377 Entity that keeps synchronised PF parameters and their associated hardware.
385 <why>The hardware minimal access may be bigger than one parameter.</why>
393 ### Read hardware
395 hardware.
398 #### Write hardware  argument
400 hardware.
401 <why>to synchronise hardware on parameter change.</why>
412 the hardware. For example a syncer might need each to know each associated
413 parameter type to send it to the hardware.</why>
430 All syncers mapping to the same hardware **SHOULD** have their builders regrouped
436  - Why is there a requirement of "same hardware" ?
440 <why>To be able to link a group of parameters and a given hardware.
493 Syncer **SHOULD** synchronise the mapped hardware on parameter change.
494 <why>To always keep synchronise the underlined hardware and the PF
497 ### Read hardware
498 Syncer **SHOULD** retrieve parameter value from the hardware if no value has be
501 with the mapped hardware current state.</note>
502 <why>To allow introspection of the hardware.</why>
511 Syncers **MAY** report an 'out-of-sync' condition indicating that the hardware
514 <why>This can happen when the underlying hardware subsystem
519 the hardware values.
525 The PF offers parameters mapped on hardware. This is a good but weak
526 abstraction as there is often a 1/1 relation between a parameter and the hardware
527 it maps. Ie: parameter abstract how to access hardware and what hardware but
528 are still hardware specific.
674 the hardware can not be abstracted in this state witch defeats the PF purpose.</why>
958 <why>The PF aims to be a hardware abstraction thus middle ware which is often
978  - hardware description
1038 <why>For performance reason or when an hardware does not support certain
1044 For performance reason only the changed parameters should be send to hardware.</why>
1094 <why>To permit hardware read only value reflection.</why>