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).
Change MockPin (and MockPWMPin) to make them behave more like 'real' pins - fixes#206
Add new MockPin tests, and rework some of the existing ones
Incorporate #216
* 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.
The prototypes in the docs are rigged to make out the first parameter as
mandatory (as it effectively is); however this does mean you've got to
remember to update the prototype when you modify it in the code! :)
Change parent of PWMOutputDevice to OutputDevice and implement blink to
maintain compatibility. The version of blink implemented here is
slightly extended to include functionality like Explorer HAT's "pulse".
The parameter defaults behave identically to OutputDevice's blink but
can be adjusted to have the device smoothly fade in and out.
