Files
python-gpiozero/docs/api_generic.rst
Dave Jones 759a6a58e6 Fix #140, fix #69, fix #185
This PR adds a software SPI implementation. Firstly this removes the
absolute necessity for spidev (#140), which also means when it's not
present things still work (effectively fixes #185), and also enables any
four pins to be used for SPI devices (which don't require the hardware
implementation).

The software implementation is simplistic but still supports clock
polarity and phase, select-high, and variable bits per word. However it
doesn't allow precise speeds to be implemented because it just wibbles
the clock as fast as it can (which being pure Python isn't actually that
fast).

Finally, because this PR involves creating a framework for "shared"
devices (like SPI devices with multiple channels), it made sense to bung
Energenie (#69) in as wells as this is a really simple shared device.
2016-04-01 12:57:17 +01:00

131 lines
3.1 KiB
ReStructuredText

===============
Generic Devices
===============
.. currentmodule:: gpiozero
The GPIO Zero class hierarchy is quite extensive. It contains several base
classes:
* :class:`Device` is the root of the hierarchy, implementing base functionality
like :meth:`~Device.close` and context manager handlers.
* :class:`GPIODevice` represents individual devices that attach to a single
GPIO pin
* :class:`SPIDevice` represents devices that communicate over an SPI interface
(implemented as four GPIO pins)
* :class:`CompositeDevice` represents devices composed of multiple other
devices like HATs
There are also several `mixin classes`_:
* :class:`ValuesMixin` which defines the ``values`` properties; there is rarely
a need to use this as the base classes mentioned above both include it
(so all classes in GPIO Zero include the ``values`` property)
* :class:`SourceMixin` which defines the ``source`` property; this is generally
included in novel output device classes
* :class:`SharedMixin` which causes classes to track their construction and
return existing instances when equivalent constructor arguments are passed
.. _mixin classes: https://en.wikipedia.org/wiki/Mixin
The current class hierarchies are displayed below. For brevity, the mixin
classes (and some other details) are omitted, and the chart is broken into
pieces by base class. The lighter boxes represent classes that are "effectively
abstract". These classes aren't directly useful without sub-classing them and
adding bits.
First, the classes below :class:`GPIODevice`:
.. image:: images/gpio_device_hierarchy.*
Next, the classes below :class:`SPIDevice`:
.. image:: images/spi_device_hierarchy.*
Next, the classes below :class:`CompositeDevice`:
.. image:: images/composite_device_hierarchy.*
Finally, for composite devices, the following chart shows which devices are
composed of which other devices:
.. image:: images/composed_devices.*
Base Classes
============
.. autoclass:: Device
:members: close, closed
.. autoclass:: GPIODevice(pin)
:members:
.. autoclass:: CompositeDevice
:members:
.. autoclass:: SPIDevice
:members:
Input Devices
=============
.. autoclass:: InputDevice(pin, pull_up=False)
:members:
.. autoclass:: WaitableInputDevice
:members:
.. autoclass:: DigitalInputDevice(pin, pull_up=False, bounce_time=None)
:members:
.. autoclass:: SmoothedInputDevice
:members:
Output Devices
==============
.. autoclass:: OutputDevice(pin, active_high=True, initial_value=False)
:members:
.. autoclass:: DigitalOutputDevice(pin, active_high=True, initial_value=False)
:members:
.. autoclass:: PWMOutputDevice(pin, active_high=True, initial_value=0, frequency=100)
:members:
SPI Devices
===========
.. autoclass:: SPIDevice
:members:
.. autoclass:: AnalogInputDevice
:members:
Composite Devices
=================
.. autoclass:: CompositeOutputDevice
:members:
.. autoclass:: LEDCollection
:members:
Mixin Classes
=============
.. autoclass:: ValuesMixin(...)
:members:
.. autoclass:: SourceMixin(...)
:members:
.. autoclass:: SharedMixin(...)
:members: _shared_key