Move the API to the end, recipes all grouped together up-front (with
remote GPIO setup just before the remote GPIO recipes). Tweak some
headings so everything looks a little more consistent in the (now
shorter) ToC.
Also added module index tags.
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).
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.
Adds a keyboard controlled robot recipe that uses curses. Advantage is
that no external deps are required, disadvantages are that it'll only
work from a terminal (or terminal window, basically not IDLE).
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.
Knew I'd missed some patches to the docs! This re-applies the
aforementioned doc patches and also fixes the last RGBLED example (which
was subtly incorrect in the original docs)
