New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bindings: python #5
Comments
Seems like ctypes is the way to go and it should be quite easy to implement. |
@brgl do you know if anyone has thus far utilized libgpiod from Python? I maintain the Adafruit BeagleBone library (Adafruit_BBIO) and I am exploring how to support the new GPIO character device interface. |
Hi @pdp7 Yes, I was recently contacted by @sgjava who showed me his automatically generated ctypes bindings. You can find them here. However I plan to write object oriented python 3 bindings (using C extensions) right after I finish the C++ bindings. There were some issues raised on the linux-gpio mailing list about the safety of ctypes for public structures with different memory layout on 32 and 64 bit architectures. Please note that I just released v1.0 of libgpiod with an improved API which shall remain stable from now on. |
Perfect timing on this query, I have similar ideas as @pdp7 around the RPi.GPIO stuff and was thinking (only an idea ATM) something around this as a GSOC [1] project. Good news on v1, will updated Fedora packages :) |
@pdp7 @nullr0ute I've started a new project that covers user space GPIO, SPI, I2C, MMIO and Serial interfaces with libgpiod + c-periphery https://github.com/sgjava/userspaceio This will generate Python and Java bindings that work on 32 and 64 bit architectures. Also, I'm targeting Python 2.7, but 3.x generation should work as well (ctypesgen is used on the target platform, so I didn't experience the issus @brgl described above). This shouldn't overlap with @brgl 's work. The scripts currently support Armbian (but should work with other Ubuntu/Debian distros work as well). If you want to support other distros submit a PR and I'll add the scripts. The idea is to have a cross SBC platform / cross language support by generating the bindings over user space APIs. A RPi.GPIO clone should be easy to generate from my Python bindings over libgpiod. See https://github.com/rm-hull/OPi.GPIO for an example using old sysfs interface. |
I feel with py2 being EOL in ~ 2 years, and hence being in maintenance mode, that py3 should be a reasonable priority for new projects like this :) |
@nullr0ute it shouldn't be a big deal. I'll look at making that the default. This is the beauty of code generation. OK, looks like CFFI is the way to go. This is a good post https://www.paypal-engineering.com/2016/09/22/python-by-the-c-side I've already kind of gone down this road. I started with SWIG, then ctypes, now CFFI. At least I only spent a few weeks going over the whole life cycle of code generators :) |
OK @nullr0ute , using compile in CFFI failed because it cannot handle include directives (i.e. ffi.compile()). I was able to get CFFI working with ABI inline. This is pretty slick and code will work with Python 2/3: Name: gpiochip1, label: 1f02c00.pinctrl, lines: 32
|
@pdp7 @nullr0ute https://github.com/sgjava/userspaceio is Python 3 bindings using CFFI! |
@sgjava thanks, that looks very interesting! |
I'm working on a RPi.GPIO clone, so you can use Luma.OLED stuff on multiple SBCs. |
A clone of RPi.GPIO isn't really of much use TBH, it needs to be accepted upstream into it. The reason is because it needs to be able to work with all the 100s of existing howtos, educational instructions, blogs etc around the internet. Without that all the non Raspbian distributions still end up with 100s of support queries of "X doesn't work with your distro" and redirecting people to some other resource doesn't work well. Raspbian themselves also won't adopt the new way of doing things because of support issues too. Unfortunately the support just needs to be upstream and seamless to the end user. |
No, I'm talking about something like https://github.com/rm-hull/OPi.GPIO in order to use Luma.OLED. I'm actually not interested in RPi.GPIO for any reason other than to extend it to non-Pi platforms that requires RPi.GPIO. OPi.GPIO is based on sysfs, so it can miss events, etc. I'm not interested in reinventing the RPi.GPIO wheel since libgpiod provides a better API in my opinion. |
Hey, @sgjava @pdp7 @nullr0ute @smurfix you guys may be interested in the latest commit in libgpiod's master branch. I pushed the first version of native Python 3 bindings for the library. I still need to figure out how to cross-compile it using autotools (I have an issue with AX_PYTHON_DEVEL macro described here. It would be great if you could give it a try and help me test it. It'll be released as part of v1.1 release together with C++ bindings. |
This is in master? |
Yes, commit 96c524c |
Just tried to build on Armbian and I get:
|
@sgjava You need the autoconf-archive package to build now. If you don't have it, this macro (AX_CXX_COMPILE_STDCXX_11) doesn't get expanded. You also need to specify the --enable-bindings-python option in configure. If your autoconf-archive macros are in some strange place, you need to run autoreconf with -I. EDIT: depending on your environment you may also need to pass PYTHON_VERSION=3 to configure. |
@sgjava FYI autoreconf will now complain about unexpanded m4 macros with a clear error message. |
OK, will try again tonight when I get home. |
@brgl I installed autoconf-archive and python3-dev and used PYTHON_VERSION=3. It worked with:
|
@brgl trying to run python example (do you install as a pip3 module?): gpiod.a gpiod.la gpiod.so are in /usr/local/lib/python3.5/site-packages
|
@brgl I fixed it with export PYTHONPATH=/usr/local/lib/python3.5/site-packages. I assume because sys.path has the default 2.7 stuff in Ubuntu.
|
@pdp7 @nullr0ute @smurfix https://github.com/sgjava/userspaceio now builds libgpiod master. I removed my CFFI bindings and will use @brgl bindings instead. I need to refactor my example Python code. I also need to test the JNA Java bindings against this build. :) |
I built a simple example that reads the built in button and optionally will turn an LED on and off based on the button state. https://github.com/sgjava/userspaceio/blob/master/libgpiod/python/src/buttonpress.py The Python bindings are easier than using CFFI wrapper I wrote for libgpiod 1.0. I'll continue to update my Python examples. |
Python bindings can now be correctly cross-compiled. An example buildroot recipe is available in my github repo. |
So testing 1.1 it all builds fine for me on Fedora except on 64 bit arches the python bindings are being installed to /usr/lib/ rather than /usr/lib64. not had time to work out the fix as yet. |
My issue was a cut/paste error, all built for Fedora for 28+ will ask people to test and provide feedback |
Cool, thanks. I was on vacation and didn't have time to look at it in the last three weeks. |
Another example for cross compiling libgpiod with python bindings is available in PTXdist git repo now. |
Native bindings implemented. |
I'm getting stuck with import gpiod. I'd rather not write a OOP wrapper to the command line functions if there are already bindings available. |
@Careknight I have never packaged libgpiod python bindings for pip. I have no need for it as I either use the package in yocto/buildroot or build it from sources. I guess this isn't available yet. |
alias python=python3 Check and make sure packages are in /usr/local/lib/python3.5/site-packages. In Ubuntu 18.04 they are in /usr/local/lib/python3.6/site-packages |
@sgjava So ultimately I understand that I'm missing the dependency, I'm trying to understand how I get it :) @brgl I appreciate that, Is there a view that this could be done in the future? |
Take a look at my script https://github.com/sgjava/userspaceio/blob/master/libgpiod/install.sh It works fine and deposits the libgpiod python artifacts in dir I described above. I'll check later tonight and give you a list of artifacts in the site-packages dir. Also, some distros are including libgpiod, but I don't think any of them are mainstream (i.e. Fedora). |
@sgjava Fedora has libgpid 1.1.1 inc the c++ and python bindings enabled, I'm the maintainer. Any feedback/fixes/suggestions welcome too. |
@Careknight I don't know much about pip packages so I will probably not do it anytime soon. I only keep the meta-openembedded and buildroot packages up to date. Everything else is packaged by others (really appreciated BTW). |
@brgl Making pip wrappers shouldn't be too hard. Maybe when I have some time I'll add it to https://github.com/sgjava/userspaceio For pip package you just need a setup.py and sudo -H pip install -e . |
Implement python bindings for libgpiod.
The text was updated successfully, but these errors were encountered: