This implements the proposal discussed in the re-opened #279 to add a
pin_factory argument at the device level and remove the ability to
specify a pin instance to device constructors (they now only accept a
pin specification).
Note: there's still a couple of bits to tidy up (tests on "real" Pis,
and pin_factory.release_all needs refinement) but the test suite is now
at least capable of passing on a PC.
Some fairly major changes to ensure that the Pin.when_changed property
doesn't keep references to the objects owning the callbacks that are
assigned. This is vaguely tricky given that ordinary weakref's can't be
used with bound methods (which are ephemeral), so I've back-ported
weakref.WeakMethod from Py3.4.
This solves a whole pile of things like Button instances not
disappearing when they're deleted, and makes composite devices
containing Buttons much easier to construct as we don't need to worry
about partially constructed things not getting deleted.
Sorry! Dave's messing around with the pin implementations again.
Hopefully the last time. The pin_factory is now really a factory object
which can be asked to produce individual pins or pin-based interfaces
like SPI (which can be supported properly via pigpio).
Overhaul the pi_info system:
Pin factories are now capable of generating pi_info themselves (although
currently they all just look up the revision and call pi_info with a
specific one).
PiGPIOPin will now return pi_info for the remote pi which can be
specified by parameter or implicitly by the environment vars.
Overvolted Pis should work properly no matter what (some argument over
whether the revision 7 or 8 chars in this case; both should work). Added
some minor tweaks for the new camera-capable Pi Zero
Finally, added a bunch of tests for pins.data
Related to @lurch's comments on #148, this PR contains a database of
pins for each Pi revision, along with various other bits of miscellany
(I might've gotten a bit carried away here...).
Any corrections/extensions welcome!
This commit is a fairly major piece of work that abstracts all pin
operations (function, state, edge detection, PWM, etc.) into a base
"Pin" class which is then used by input/output/composite devices to
perform all required configuration.
The idea is to pave the way for I2C based IO extenders which can present
additional GPIO ports with similar capabilities to the Pi's "native"
GPIO ports. As a bonus it also abstracts away the reliance on the
RPi.GPIO library to allow alternative pin implementations (e.g. using
RPIO to take advantage of DMA based PWM), or even pure Python
implementations.
