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 is just a quicky for people to start playing with - it's not
complete in any way, shape, or form. This is how I envisage the "real"
pin tests being done; part of the test suite with a `skipif` to ensure
they don't get run on non-Pi platforms, with a fixture to loop over
whatever pin implementations are found (we can't always assume all of
them: for example, RPIO doesn't work on a Pi 2), and a relatively simple
wiring for the test.
In this case I've assumed GPIOs 22 and 27 are wired together. They're
next to each other, so a jumper is sufficient to run the test.
PRs extending the coverage are very welcome (I've already discovered and
fixed several silly bugs in NativePin!). I've left all the interesting
hard stuff for people to play with (PWM testing: statistical sampling?
debounce compensation testing: timing?). When I've got a second, I'll
looking into hooking up my Pi Zero as a Travis-esque test-bed for this,
triggered by GitHub webhooks (not sure how I'll deal with reporting
yet).
* rename FUNCTION / PULL / EDGES dictionaries so that they better-match the other `Pin` implementations
* throw `PinSetInput` if trying to set the state of an input pin
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.
