Permit replacement of pin_factory without closing old factory. However,
continue closing devices associated with extant pin factory at script
termination.
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
Also re-numbers energenie sockets 1-4 (as noted by @bennuttall in
comments to #239), and adds several "real pins" tests and board tests.
The bad-PWM stuff is currently disabled as it causes segfaults when
running the tests and I can't seem to trace the cause at the moment.
Finally, I've tweaked the deb config to suggest gpiozero, removed spidev
as a mandatory dep (which'll fix installs on wheezy for py3), and
there's some more miscellaneous last-minute stuff here that I can't
recall...
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.
