Added notes on how the abstracts are represented, ensured all the class
hierarchies were up to date, and changed the orientation so the classes
are actually readable in the big chart.
This is almost a straight copy'n'paste of picamera's development chapter
with a few minor changes to make it read sensibly for GPIO Zero; it
needs plenty more work to fulfil the goals of #451 but hopefully this'll
act as a reasonable base for people to work on.
Ensure LEDCollection cleans up upon construction failure, rename some
internals to be a bit more obvious, rename PinGPIOUnsupported to
PinUnsupported, and some other stuff I've forgotten!
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).
* Use Python syntax highlighting
* Use code directive instead
* use python syntax highlighting in the docs
* update Programming Language classifers for supported Python versions
* use %s instead
Added SPI tests, simplified the shared SPI software bus implementation,
and fixed several protocol errors in our MCP3xxx classes (the x2 and x1
protocols were wrong)
Add Servo and AngularServo implementation along with docs and tests.
This is a deliberately minimal implementation designed to be added to as
we agree on new extensions (better than making an all-singing,
all-dancing version in which I get things wrong and then wind up making
backward incompatible changes to get it right :)
In particular the `pi_revision` thing in PiGPIOPin, all the stuff @lurch
picked up in `pins/data.py` (thank goodness *someone's* watching!), and
make all those links pointing to "Notes" point somewhere useful like
"Pin Numbering"...
Tweak the second keyboard robot recipe so it detects keyboards and
doesn't throw exceptions on unknown keys. Also add a note to the recipe
that it won't work over remote connections like SSH.
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
