This PR implements SnowPi, adds the ability for LEDBoard's to own other
LEDBoards as well as LEDs, and enhances blink so that manually
controlling a LED automatically stops it from blinking (no matter
whether it's blinking itself or a LEDBoard is blinking it).
It also fixes up RGBLED and Motor which I managed to break with the last
PR ...
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.
Added source_delay property to SourceMixin which means it'll now appear
everywhere. Default is 0.01 which is just enough to drop CPU usage while
remaining responsive enough for the majority of purposes.
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
