hardware
Classes that manage hardware logic.
Each hardware class should be able to operate independently - ie. not be dependent on a particular task class, etc. Other than that there are very few design requirements:
Every class should have a .release() method that releases any system resources in use by the object, eg. objects that use pigpio must have their pigpio.pi client stopped; LEDs should be explicitly turned off.
The very minimal class attributes are described in the
Hardware
metaclass.Hardware methods are typically called in their own threads, so care should be taken to make any long-running operations internally threadsafe.
Note
This software was primarily developed for the Raspberry Pi, which has two types of numbering schemes , “board” numbering based on physical position (e.g. pins 1-40, in 2 rows of 20 pins) and “bcm” numbering based on the broadcom chip numbering scheme (e.g. GPIO2, GPIO27).
Board numbering is easier to use, but pigpio , which we use as a bridge between Python and the GPIOs, uses the BCM scheme. As such each class that uses the GPIOs takes a board number as its argument and converts it to a BCM number in the __init__ method.
If there is sufficient demand to make this more flexible, we can implement an additional pref to set the numbering scheme, but the current solution works without getting too muddy.
Data:
Mapping from board (physical) numbering to BCM numbering. |
|
The inverse of |
Classes:
|
Generic class inherited by all hardware. |
- BOARD_TO_BCM = { 3: 2, 5: 3, 7: 4, 8: 14, 10: 15, 11: 17, 12: 18, 13: 27, 15: 22, 16: 23, 18: 24, 19: 10, 21: 9, 22: 25, 23: 11, 24: 8, 26: 7, 29: 5, 31: 6, 32: 12, 33: 13, 35: 19, 36: 16, 37: 26, 38: 20, 40: 21}
Mapping from board (physical) numbering to BCM numbering.
See this pinout.
Hardware objects take board numbered pins and convert them to BCM numbers for use with pigpio.
- Type
- BCM_TO_BOARD = { 2: 3, 3: 5, 4: 7, 5: 29, 6: 31, 7: 26, 8: 24, 9: 21, 10: 19, 11: 23, 12: 32, 13: 33, 14: 8, 15: 10, 16: 36, 17: 11, 18: 12, 19: 35, 20: 38, 21: 40, 22: 15, 23: 16, 24: 18, 25: 22, 26: 37, 27: 13}
The inverse of
BOARD_TO_BCM
.- Type
- class Hardware(name=None, group=None, **kwargs)[source]
Bases:
object
Generic class inherited by all hardware. Should not be instantiated on its own (but it won’t do anything bad so go nuts i guess).
Primarily for the purpose of defining necessary attributes.
- Variables
name (str) – unique name used to identify this object within its group.
group (str) – hardware group, corresponds to key in prefs.json
"HARDWARE": {"GROUP": {"ID": {**params}}}
is_trigger (bool) – Is this object a discrete event input device? or, will this device be used to trigger some event? If True, will be given a callback by
Task
, andassign_cb()
must be redefined.pin (int) – The BCM pin used by this device, or None if no pin is used.
type (str) – What is this device known as in .prefs? Not required.
input (bool) – Is this an input device?
output (bool) – Is this an output device?
Attributes:
Calibration used by the hardware object.
Methods:
release
()Every hardware device needs to redefine release(), and must
assign_cb
(trigger_fn)Every hardware device that is a
trigger
must redefine this to accept a function (typicallyTask.handle_trigger()
) that is called when that trigger is activated.get_name
()Usually Hardware is only instantiated with its pin number, but we can get its name from prefs
init_networking
([listens])Spawn a
Net_Node
toHardware.node
for streaming or networked command- is_trigger = False
- pin = None
- type = ''
- input = False
- output = False
- logger: logging.Logger
- release()[source]
Every hardware device needs to redefine release(), and must
Safely unload any system resources used by the object, and
Return the object to a neutral state - eg. LEDs turn off.
When not redefined, a warning is given.
- assign_cb(trigger_fn)[source]
Every hardware device that is a
trigger
must redefine this to accept a function (typicallyTask.handle_trigger()
) that is called when that trigger is activated.When not redefined, a warning is given.
- get_name()[source]
Usually Hardware is only instantiated with its pin number, but we can get its name from prefs
- init_networking(listens=None, **kwargs)[source]
Spawn a
Net_Node
toHardware.node
for streaming or networked command- Parameters
listens (dict) – Dictionary mapping message keys to handling methods
**kwargs – Passed to
Net_Node
Returns:
- property calibration: Optional[dict]
Calibration used by the hardware object.
Attempt to read from
prefs.get('CALIBRATIONDIR')/group.name.json
, ifHardware.group
isNone
, attempt to read fromprefs.get('CALIBRATIONDIR')/name.json
Setting the attribute (over)writes the calibration to disk as a .json file
Will be different for each hardware type, subclasses should document this property separately (eg. by overwriting
Hardware.calibration.__doc__
- Returns
if calibration is found, a dictionary of calibration for each property. None if no calibration found
- Return type
(dict)