PyBBIO update – version 0.8.5
This is really the first official PyBBIO update, but I'll try to make it a more regular thing.
Why do this? Because going behind Kernel drivers' backs is just plain wrong! When I first started working on PyBBIO the BeagleBone kernel was in a very different state, and most of the IO was done through hacks of one sort or another. But with the introduction of the Device Tree to the BeagleBone with Kernel 3.8, and thanks to all the great driver development from TI and other BeagleBone users, it now makes much more sense to take a fully Kernel driver based approach as I move forward with PyBBIO.
If you're wondering whether this change will slow down PyBBIO's GPIO, the answer is yes, by orders of magnitude! But if you need high speed GPIO, you really shouldn't be controlling it from user-space Linux. In fact, if you want high-speed GPIO on the BeagleBone, that's what the PRUSS is for! (Some of my notes and resources on using the PRUs is on Github here)
The mmap based version is still available (without any support or further development) on its own mmap-gpio branch.
I've also fixed the USR LEDs, which hadn't been working for quite some time (oops!).
There's now six PWM outputs working on Kernel 3.8: the 4 ePWM outputs that were previously working, plus eCAP0 and eCAP1. (ECAP0 and ECAP1 variables in PyBBIO)
Deepak Karki contributed a great I2C library, thanks Deepak! It provides the two objects Wire1 and Wire2, which have an interface similar to the Arduino Wire library. Documentation to come. (source code here)
With Kernel 3.8 came the Device Tree, which was a pretty major speed bump for user-space IO libraries because it completely changed the interface to enable and configure the AM3359's subsystems.
The way PyBBIO handles this is to dynamically create small and very specific Device Tree overlays during installation. These include separate overlays for each GPIO pin, for example. My reasoning for taking this approach, rather than having a single huge PyBBIO overlay, is that it means PyBBIO is inherently compatible with cape overlays because it only uses the resources you explicitly tell it to.