This is a mirror of the original repository over at kernel.org. This github page is for discussions and issue reporting only. PRs can be discussed here but the patches need to go through the linux-gpio mailing list.
Home Page: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
License: Other
root@OpenWrt:/libgpiod# ./autogen.shobsolete.m4'
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
aclocal: warning: couldn't open directory 'm4': No such file or directory
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory autostuff
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'autostuff'.
libtoolize: copying file 'autostuff/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: aclocal --force -I m4
autoreconf: running: /usr/bin/autoconf --force
configure.ac:75: warning: The macro AC_HEADER_STDC' is obsolete. configure.ac:75: You should run autoupdate. ./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from... configure.ac:75: the top level configure.ac:85: error: possibly undefined macro: AC_CHECK_HEADERS If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:203: error: Unexpanded AX_ macro found. Please install GNU autoconf-archive. configure.ac:208: error: possibly undefined macro: AC_LANG_PUSH configure.ac:210: error: possibly undefined macro: AC_LANG_POP autoreconf: error: /usr/bin/autoconf failed with exit status: 1 root@OpenWrt:~/libgpiod# ./autogen.sh --enable-tools=yes autoreconf: export WARNINGS= autoreconf: Entering directory '.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4 autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'autostuff'. libtoolize: copying file 'autostuff/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'. libtoolize: copying file 'm4/libtool.m4' libtoolize: copying file 'm4/ltoptions.m4' libtoolize: copying file 'm4/ltsugar.m4' libtoolize: copying file 'm4/ltversion.m4' libtoolize: copying file 'm4/lt~obsolete.m4' autoreconf: configure.ac: not using Intltool autoreconf: configure.ac: not using Gtkdoc autoreconf: running: aclocal --force -I m4 autoreconf: running: /usr/bin/autoconf --force configure.ac:75: warning: The macro AC_HEADER_STDC' is obsolete.
configure.ac:75: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:75: the top level
configure.ac:85: error: possibly undefined macro: AC_CHECK_HEADERS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:203: error: Unexpanded AX_ macro found. Please install GNU autoconf-archive.
configure.ac:208: error: possibly undefined macro: AC_LANG_PUSH
configure.ac:210: error: possibly undefined macro: AC_LANG_POP
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
Hello
More likely it's not libgpiod fault itself.
I'm using Yocto on iMX6ULL single board computer and I wanted to create default gpio configuration inside device-tree according this doc:
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
&gpio1{
bat {
gpio-hog;
gpios = <5 GPIO_ACTIVE_HIGH>;
input;
line-name = "BAT";
};
chrg_stop {
gpio-hog;
gpios = <12 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "CHARGE_STOP";
};
};
When i use gpioinfo everything looks fine, exept that this configured gpio lines are marked as already used(this leds, and button are driven by gpio-leds and gpio-keys kernel modules so it is the reason why are marked as used):
gpioinfo /dev/gpiochip0
gpiochip0 - 32 lines:
line 0: unnamed unused input active-high
line 1: unnamed unused input active-high
line 2: unnamed unused input active-high
line 3: unnamed unused input active-high
line 4: unnamed unused input active-high
line 5: unnamed "BAT" input active-high [used]
line 6: unnamed unused input active-high
line 7: unnamed unused input active-high
line 8: unnamed unused input active-high
line 9: unnamed "BTN_OK" input active-high [used]
line 10: unnamed "LED0" output active-high [used]
line 11: unnamed "LED1" output active-high [used]
line 12: unnamed "CHARGE_STOP" output active-high [used]
Reading kernel debug file as mentioned here:
https://stackoverflow.com/questions/16033748/how-do-can-i-find-out-which-linux-driver-is-hogging-my-gpio
gives:
root@visionsom6ull:/sys/kernel/debug# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-31, parent: platform/209c000.gpio, 209c000.gpio:
gpio-5 ( |BAT ) in lo
gpio-9 ( |BTN_OK ) in hi
gpio-10 ( |LED0 ) out lo
gpio-11 ( |LED1 ) out lo
gpio-12 ( |CHARGE_STOP ) out hi
I can't figure out which one component is using those named lines.
Is gpio manipulation on pins like that even possible from userspace?
All I need to do is to read one signal, and set another.
It is too easy task to write special kernel module.
The documentation is very incomplete. Not only it lacks some quick start guide (e.g. get the chip - get the line info - create a line request, etc) or a migration guide from 1.x versions, but also some of the functions are missing. For the example, check the Line info section. There are number of function listed that operate on struct gpiod_line_info *, but not a single function to obtain this struct. The header file has the gpiod_chip_get_line_info function but it is not documented.
As a result, it is virtually impossible to deduce from the documentation how the API should be used.
Thank you !
I've been using this lib for 2 months to use my GPIO with a C program.
It's going great!
Olaf from Germany
Hello,
Seth here. I am having trouble configuring my BBB (Linux Debian Distro) 4.14.x.
configure: error: Package requirements (libkmod >= 18) were not met:
No package 'libkmod' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables KMOD_CFLAGS
and KMOD_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
I have been trying to compile at this stage:
~/libgpiod$ sudo ./configure --enable-tests
...
I have gotten nowhere so far. I know this is not easy and I should have researched my failure further but...
Do you have any ideas on this situation?
Seth
P.S. I am currently trying to learn how to label my BBB w/ userspaceIO and libgpiod (w/ respective tool cmds).
The unit tests framework is already partially implemented in master. What is still missing are the event tests and getting to 95%+ code coverage. This needs to wait however for linux 4.11 when all required functionalities of gpio-mockup will be available upstream.
I implementing gpiod for a 1wire bus on an Odroid N2L. The bus has a pull-up resistor so I added the flag for that to the line request:
gpiod_line_request_output_flags(gpioline,"DS18B20",GPIOD_LINE_REQUEST_FLAG_OPEN_DRAIN|GPIOD_LINE_REQUEST_FLAG_BIAS_PULL_UP,1);
The code failed with errno 22. Removing the flag prevented the error and the code works flawlessly. So it seems that it is a bug.
Implement a C++ interface for libgpiod.
Doxygen generation is currently broken. When you browse to libgpiod/doc/html/modules.html, the list of all modules is only this: >common</strong> Common helper macros | Commonly used utility macros
These are the build errors I get:
nettings@hoppetosse:~/github/libgpiod> make doc
/home/nettings/github/libgpiod/include/gpiod.h:79: warning: group strong: ignoring title ">high_level</strong> High-level API" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:386: warning: group strong: ignoring title ">chips</strong> GPIO chip operations" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:523: warning: group strong: ignoring title ">lines</strong> GPIO line operations" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:528: warning: group strong: ignoring title ">line_bulk</strong> Operating on multiple lines" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:636: warning: group strong: ignoring title ">line_info</strong> Line info" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:754: warning: group strong: ignoring title ">line_request</strong> Line requests" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:1073: warning: group strong: ignoring title ">line_value</strong> Reading & setting line values" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:1124: warning: group strong: ignoring title ">line_event</strong> Line events handling" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:1208: warning: group strong: ignoring title ">line_misc</strong> Misc line functions" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:1259: warning: group strong: ignoring title ">iterators</strong> Iterators for GPIO chips and lines" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:1383: warning: group strong: ignoring title ">misc</strong> Stuff that didn't fit anywhere else" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/bindings/cxx/gpiod.hpp:26: warning: group strong: ignoring title ">gpiod_cxx</strong> C++ bindings" that does not match old title ">common</strong> Common helper macros"
/home/nettings/github/libgpiod/include/gpiod.h:528: warning: Refusing to add group strong to itself
/home/nettings/github/libgpiod/include/gpiod.h:636: warning: Refusing to add group strong to itself
/home/nettings/github/libgpiod/include/gpiod.h:754: warning: Refusing to add group strong to itself
/home/nettings/github/libgpiod/include/gpiod.h:1073: warning: Refusing to add group strong to itself
/home/nettings/github/libgpiod/include/gpiod.h:1124: warning: Refusing to add group strong to itself
/home/nettings/github/libgpiod/include/gpiod.h:1208: warning: Refusing to add group strong to itself
Probably a simple syntax error somewhere, but I'm not too familiar with doxygen. Will see if I can find it myself, if not: now you know.
I'm simply running gpiodetectcxx.cpp on my PC, where there is no gpiochip in /dev. It quits with a segfault.
The problem is, that the chip_iter is creating a chip with a gpiod_chip set to NULL and the deleter is calling ::gpiod_chip_close(chip); which crashes because it dereferences a NULL-pointer.
I don't know how to fix it properly. I added locally a NULL-check inside the gpiod_chip_close-function.
My pull request at #6 contains two musl compatibility fixes. However, even with those fixes, one issue remains: src/lib/core.c uses the GNU variant of strerror_r(), while musl only provides the XSI variant of the function. This causes only a warning at compile time, but will cause a real issue at runtime, since the code is casting the "int" result of musl strerror_r() into a "char *".
If we're dying during test execution, the [FATAL] error message is not prepended with a newline.
Currently gpiomon prints human readable event reports which are not very suitable for automated parsing. Introduce an option to specify custom formats e.g. --format="%c %o %e" would result in the following output: gpiochip0 4 0 where 4 indicates the line offset and 0 indicates a falling-edge event.
Hello, I really like the improvements in the latest version and I wonder if there are plans to add an update to the apt repository?
I have cloned libgpiod from this web site (brgl/libgpiod). I am having problems building libgpiod.
I am running the software on a Raspberry PI 3B+ using Raspbian Buster OS.
I have successfully used sysfs in the run-time of my event-driven language immediate C for over 8 years to set GPIO outputs and generate interrupts from GPIO inputs and read them. Since sysfs is deprecated I want to migrate my code to libgpiod.
I installed the following:
apt install autoconf
apt install autoconf-archive
I initially executed:
sudo apt install gpiod libgpiod-dev libgpiod-doc
Trying to compile examples from that install showed that the gpiod.. C functions were not present. I then cloned libgpiod.
Following the Build instructions I executed:
./autogen.sh --enable-tools=yes --prefix=/usr/local
This output the following error messages:
autoreconf: Entering directory .'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
aclocal: warning: couldn't open directory 'm4': No such file or directory
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
bindings/cxx/Makefile.am:4: error: Libtool library used but 'LIBTOOL' is undefined
bindings/cxx/Makefile.am:4: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
bindings/cxx/Makefile.am:4: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
bindings/cxx/Makefile.am:4: If 'LT_INIT' is in 'configure.ac', make sure
bindings/cxx/Makefile.am:4: its definition is in aclocal's search path.
lib/Makefile.am:4: error: Libtool library used but 'LIBTOOL' is undefined
lib/Makefile.am:4: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
lib/Makefile.am:4: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
lib/Makefile.am:4: If 'LT_INIT' is in 'configure.ac', make sure
lib/Makefile.am:4: its definition is in aclocal's search path.
tests/gpiosim/Makefile.am:4: error: Libtool library used but 'LIBTOOL' is undefined
tests/gpiosim/Makefile.am:4: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
tests/gpiosim/Makefile.am:4: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
tests/gpiosim/Makefile.am:4: If 'LT_INIT' is in 'configure.ac', make sure
tests/gpiosim/Makefile.am:4: its definition is in aclocal's search path.
tools/Makefile.am:7: error: Libtool library used but 'LIBTOOL' is undefined
tools/Makefile.am:7: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
tools/Makefile.am:7: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
tools/Makefile.am:7: If 'LT_INIT' is in 'configure.ac', make sure
tools/Makefile.am:7: its definition is in aclocal's search path.
autoreconf: automake failed with exit status: 1`
I do not know to what path or where exactly to set LT_INIT
Hey guys, love libgpiod, but it would make things a lot easier if the API documentation of the current release could be built automatically and hosted somewhere on the web, whether here or on kernel.org.
I am moving from using sysfs to libgpiod, and so far it works pretty nicely.
But, one thing I cannot seem to do, is to read the current state of a gpio pin if it is in output-direction and set in another context.
For example: Other program sets pin to output, and to value 1.
In my program, I just want to see what value the pin is at, WITHOUT changing the direction to input (since this would change the behaivour of the pin).
In sysfs, this was easily done by just polling the value (and as long as you did not write to anything, you did not change anything.). But if I try to do this with libgpio, it returns an error if I don’t first change direction to input.
After some quick correspondance with Bartosz it seems this is currently not possible, but future plans are there for a single daemon that can be interfaced with.
Still, if it can be fixed in the library alone, it would avoid more userspace applications that are required (and have something as lightweight as sysfs (where you basically only need the kernel and no libraries).
Keeping this issue open here for other ppl to track as well:)
When I try configuring this under Ubuntu I get the following:
checking linux/gpio.h usability... no
checking linux/gpio.h presence... no
checking for linux/gpio.h... no
configure: error: linux/gpio.h header not found (needed to build the library)
I have confirmed that the linux headers are installed.
/usr/src/linux-headers-4.10.0-40/include/linux/gpio.h
Is there something else I need to give configure?
Thank you,
CM
gpiomon is no longer waiting until state change on the line; it exits with RC=0 after a few seconds as if the event has triggered, with no output.
Using:
gpiomon --rising-edge --num-events=1 gpiochip0 230
Hi, apologies for reporting a bug in a now deprecated function of an old library version, but it's what I have available on the latest Raspbian stretch.
When you call gpiod_ctxless_event_loop_multiple with no lines set (offsets is initialized to an array of zeroes, numlines is 0), it segfaults.
Would be nice if the user didn't have to add checks before calling, since it's just a degenerate case of setting up an event handler that should be legal.
Sorry if this is already fixed in the current version, right now I have no way of upgrading.
I'm a bit of a noob with embedded linux, so if there's an obvious reason for this behavior, please let me know.
I've got a BeagleBone Black and am experimenting with this library in C. Prior to using this library or the associated tools, if I wanted to set an output pin high, I would do this:
cd /sys/class/gpio
(if gpioXX directory not present, then echo XX > export)
cd gpioXX
echo 1 > value
This would keep the value high indefinitely.
When I call gpiod_ctxless_set_value("gpiochipX", Y, 1, false, NULL, NULL), the value sets high and immediately goes back to low. What's the best way of setting the value and having it stick until the next time a change it?
Thanks!
This ticket tracks the development of the DBus daemon. Current development branch can be found here.
The API is not complete yet but some parts are functional. The daemon, command-line client and tests can be built with: ./autogen.sh --enable-bindings-glib --enable-dbus --enable-tests && make. The daemon tests can be run with sudo GPIODBUS_TEST_DAEMON_PATH=dbus/manager/gpio-manager ./dbus/tests/gpiodbus-test after dbus/data/io.gpiod1.conf is installed to /etc/dbus-1/system.d/. Command-line client tests can be run with sudo PATH=<path to libgpiod>/tests/bash/:$PATH ./dbus/client/gpiocli-test.bash. In order to run these, the daemon must be started in the background first.
We need to track potential regressions in gpio-tools. Create a simple bash-based testing framework for tools using the gpio-mockup driver.
There are a number of reasons to provide precompiled wheels:
Building wheels on the command line or via pipeline is generally pretty straightforward. There is a utility called cibuildwheel that accomplishes most of this by using containers with very specific combinations of toolchains and utilities to build libraries that will work across distributions, generally rooted off of the major glibc version available.
From the command line, with an sdist:
vfazio@vfazio4 /tmp/tmp.nYZrtOYERx $ wget https://files.pythonhosted.org/packages/a8/56/730573fe8d03c4d32a31e7182d27317b0cef298c9170b5a2994e2248986f/gpiod-2.1.3.tar.gz
--2024-03-05 08:23:48-- https://files.pythonhosted.org/packages/a8/56/730573fe8d03c4d32a31e7182d27317b0cef298c9170b5a2994e2248986f/gpiod-2.1.3.tar.gz
Resolving files.pythonhosted.org (files.pythonhosted.org)... 199.232.96.223, 2a04:4e42:58::223
Connecting to files.pythonhosted.org (files.pythonhosted.org)|199.232.96.223|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 53092 (52K) [application/octet-stream]
Saving to: ‘gpiod-2.1.3.tar.gz’
gpiod-2.1.3.tar.gz 100%[==============================================================================================================>] 51.85K --.-KB/s in 0.02s
2024-03-05 08:23:49 (2.54 MB/s) - ‘gpiod-2.1.3.tar.gz’ saved [53092/53092]
vfazio@vfazio4 /tmp/tmp.nYZrtOYERx $ tar -xf gpiod-2.1.3.tar.gz
vfazio@vfazio4 /tmp/tmp.nYZrtOYERx $ cd gpiod-2.1.3/
vfazio@vfazio4 /tmp/tmp.nYZrtOYERx/gpiod-2.1.3 $ python3 -m venv venv
vfazio@vfazio4 /tmp/tmp.nYZrtOYERx/gpiod-2.1.3 $ . venv/bin/activate
(venv) vfazio@vfazio4 /tmp/tmp.nYZrtOYERx/gpiod-2.1.3 $ pip install cibuildwheel
</snip>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 69.5/69.5 KB 14.5 MB/s eta 0:00:00
Installing collected packages: typing-extensions, tomli, platformdirs, packaging, filelock, certifi, bracex, bashlex, cibuildwheel
Successfully installed bashlex-0.18 bracex-2.4 certifi-2024.2.2 cibuildwheel-2.16.5 filelock-3.13.1 packaging-23.2 platformdirs-4.2.0 tomli-2.0.1 typing-extensions-4.10.0
(venv) vfazio@vfazio4 /tmp/tmp.nYZrtOYERx/gpiod-2.1.3 $ CIBW_BUILD='cp3*' cibuildwheel --platform linux --archs x86_64,aarch64
_ _ _ _ _ _ _
___|_| |_ _ _|_| |_| |_ _ _| |_ ___ ___| |
| _| | . | | | | | . | | | | | -_| -_| |
|___|_|___|___|_|_|___|_____|_|_|___|___|_|
cibuildwheel version 2.16.5
Build options:
platform: linux
architectures: aarch64, x86_64
build_selector:
build_config: cp3*
skip_config:
requires_python: >=3.9.0
prerelease_pythons: False
container_engine: docker
output_dir: /tmp/tmp.nYZrtOYERx/gpiod-2.1.3/wheelhouse
package_dir: /tmp/tmp.nYZrtOYERx/gpiod-2.1.3
test_selector:
skip_config:
before_all:
before_build:
before_test:
build_frontend: None
build_verbosity: 0
config_settings:
dependency_constraints: pinned
environment:
manylinux_images:
x86_64: quay.io/pypa/manylinux2014_x86_64:2024-01-23-12ffabc
i686: quay.io/pypa/manylinux2014_i686:2024-01-23-12ffabc
pypy_x86_64: quay.io/pypa/manylinux2014_x86_64:2024-01-23-12ffabc
aarch64: quay.io/pypa/manylinux2014_aarch64:2024-01-23-12ffabc
ppc64le: quay.io/pypa/manylinux2014_ppc64le:2024-01-23-12ffabc
s390x: quay.io/pypa/manylinux2014_s390x:2024-01-23-12ffabc
pypy_aarch64: quay.io/pypa/manylinux2014_aarch64:2024-01-23-12ffabc
pypy_i686: quay.io/pypa/manylinux2014_i686:2024-01-23-12ffabc
musllinux_images:
x86_64: quay.io/pypa/musllinux_1_1_x86_64:2024-01-23-12ffabc
i686: quay.io/pypa/musllinux_1_1_i686:2024-01-23-12ffabc
aarch64: quay.io/pypa/musllinux_1_1_aarch64:2024-01-23-12ffabc
ppc64le: quay.io/pypa/musllinux_1_1_ppc64le:2024-01-23-12ffabc
s390x: quay.io/pypa/musllinux_1_1_s390x:2024-01-23-12ffabc
repair_command: auditwheel repair -w {dest_dir} {wheel}
test_command:
test_extras:
test_requires:
Cache folder: /home/vfazio/.cache/cibuildwheel
Here we go!
</snip>
16 wheels produced in 10 minutes:
gpiod-2.1.3-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 96 kB
gpiod-2.1.3-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 95 kB
gpiod-2.1.3-cp310-cp310-musllinux_1_1_aarch64.whl 98 kB
gpiod-2.1.3-cp310-cp310-musllinux_1_1_x86_64.whl 98 kB
gpiod-2.1.3-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 97 kB
gpiod-2.1.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 97 kB
gpiod-2.1.3-cp311-cp311-musllinux_1_1_aarch64.whl 100 kB
gpiod-2.1.3-cp311-cp311-musllinux_1_1_x86_64.whl 100 kB
gpiod-2.1.3-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 97 kB
gpiod-2.1.3-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 96 kB
gpiod-2.1.3-cp312-cp312-musllinux_1_1_aarch64.whl 102 kB
gpiod-2.1.3-cp312-cp312-musllinux_1_1_x86_64.whl 102 kB
gpiod-2.1.3-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl 95 kB
gpiod-2.1.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl 95 kB
gpiod-2.1.3-cp39-cp39-musllinux_1_1_aarch64.whl 98 kB
gpiod-2.1.3-cp39-cp39-musllinux_1_1_x86_64.whl 97 kB
This build used the default target images for building wheels, which is probably fine as they are not EOL (see https://github.com/pypa/manylinux). The one suggestion I may make is to possibly generate manylinux_2_28 wheels as the OS used to generate manylinux2014 will technically be EOL in June though may still receive support from the provided docker images beyond it's EOL date.
Having prebuilt wheels will likely also increase package adoption. I'm currently stuck on the old pure-python implementation (and thus the v1 kernel interface) until wheels are provided unless I package and deploy them to my own internal server.
Compiling on a CentOS 7.4 with a custom 4.14 kernel, I get this error trying to autoconf:
# ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `autostuff'.
libtoolize: copying file `autostuff/ltmain.sh'
libtoolize: putting macros in `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking build system type... aarch64-unknown-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /bin/ld
checking if the linker (/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /bin/nm -B
checking the name lister (/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert aarch64-unknown-linux-gnu file names to aarch64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert aarch64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /bin/ld
checking if the linker (/bin/ld) is GNU ld... yes
checking whether the g++ linker (/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for ANSI C header files... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for ioctl... yes
checking for asprintf... yes
checking for scandir... yes
checking for alphasort... yes
checking for ppoll... yes
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking linux/gpio.h usability... yes
checking linux/gpio.h presence... yes
checking for linux/gpio.h... yes
/root/libgpiod/configure: line 16727: syntax error near unexpected token `ext,'
/root/libgpiod/configure: line 16727: ` AX_CXX_COMPILE_STDCXX_11(ext, mandatory)'
Hello there!
First, I'd like to thank all who contribute to libgpiod which is really handy! :D
I'm currently developing a GPIO expander module for Linux 6.1.70 which runs on a Raspberry PI. Basic functionality should be implemented as a gpio_chip is created and provides get_direction, direction_input, direction_output, get and set functions.
For quick testing purposes I'm using a manually built libgpiod at commit fc2f2feaa99dce8aab6381168051f2725b537621 which is from january 16, so fairly recent. This is so I can make sure the executables are using libgpiod V2 (the one that comes with Raspberry PI's OS is the V1).
After loading my module, I successfully create a gpiochip. In my system, /dev/gpiochip2. This can be checked with gpiodetect:
wedev@raspberrypi:~/Downloads/libgpiod $ ./tools/gpiodetect
gpiochip0 [pinctrl-bcm2711] (58 lines)
gpiochip1 [raspberrypi-exp-gpio] (8 lines)
gpiochip2 [pi4ioe5v6416] (16 lines)
and gpioinfo 2:
gpiochip2 - 16 lines:
line 0: unnamed unused input active-high
line 1: unnamed unused input active-high
line 2: unnamed unused input active-high
line 3: unnamed unused input active-high
line 4: unnamed unused input active-high
line 5: unnamed unused output active-high
line 6: unnamed unused input active-high
line 7: unnamed unused input active-high
line 8: unnamed unused input active-high
line 9: unnamed unused input active-high
line 10: unnamed unused input active-high
line 11: unnamed unused input active-high
line 12: unnamed unused input active-high
line 13: unnamed unused input active-high
line 14: unnamed unused input active-high
line 15: unnamed unused input active-high
The problem I'm facing is that gpioget is complaining about an invalid IOCTL when I try to use it, even though gpioset works just fine.
wedev@raspberrypi:~/Downloads/libgpiod $ ./tools/gpioget -c 2 0
/home/wedev/Downloads/libgpiod/tools/.libs/gpioget: unable to read GPIO line values: Inappropriate ioctl for device
I've tracked the syscalls made by gpioget in two scenarios one of them for /dev/gpiochip0 and the other for /dev/gpiochip2
gpioget -c 2 4gpioget -c 0 4They run the same, until this point:
ioctl(3, GPIO_GET_CHIPINFO_IOCTL, {name="gpiochip2", label="pi4ioe5v6416", lines=16}) = 0
ioctl(3, GPIO_V2_GET_LINE_IOCTL, {num_lines=1, offsets=[4], consumer="gpioget", config={flags=GPIO_V2_LINE_FLAG_INPUT, num_attrs=0}} => {fd=0}) = 1
ioctl(0, GPIO_V2_LINE_GET_VALUES_IOCTL, {mask=0x1}) = -1 ENOTTY (Inappropriate ioctl for device)
write(2, "/home/wedev/Downloads/libgpiod/t"..., 52/home/wedev/Downloads/libgpiod/tools/.libs/gpioget: ) = 52
write(2, "unable to read GPIO line values", 31unable to read GPIO line values) = 31
write(2, ": Inappropriate ioctl for device"..., 33: Inappropriate ioctl for device
) = 33
exit_group(1) = ?
+++ exited with 1 +++
Notice that in line 3, I get an -ENOTTY. And that in that line, I've used 0 as the fd, which was given by the previous ioctl call.
This is an example of the right behaviour:
openat(AT_FDCWD, "/dev/gpiochip0", O_RDWR|O_CLOEXEC) = 3
ioctl(3, GPIO_GET_CHIPINFO_IOCTL, {name="gpiochip0", label="pinctrl-bcm2711", lines=58}) = 0
ioctl(3, GPIO_V2_GET_LINE_IOCTL, {num_lines=1, offsets=[4], consumer="gpioget", config={flags=GPIO_V2_LINE_FLAG_INPUT, num_attrs=0}} => {fd=4}) = 0
ioctl(4, GPIO_V2_LINE_GET_VALUES_IOCTL, {mask=0x1} => {bits=0x1}) = 0
close(4) = 0
close(3) = 0
newfstatat(1, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}, AT_EMPTY_PATH) = 0
write(1, "\"4\"=active\n", 11) = 11
exit_group(0) = ?
+++ exited with 0 +++
So I think that it's not GPIO_V2_LINE_GET_VALUES_IOCTL that is failing, but GPIO_V2_GET_LINE_IOCTL that is returning a positive value even though gpio_v2_line_request::fd is 0, which the comments at include/uapi/linux/gpio.h say should be an error.
Can someone help me figure this out?
Are the C functions provided by the libgpiod C libaray thread safe?
My current assumption is that the functions are not thread safe because functions like gpiod_line_update could be modifying data such as the string pointed to by line->consumer in one thread with this code ...
strncpy(line->consumer, info.consumer, sizeof(line->consumer));... while a second thread could be reading the same string using the const char * to line->consumer returned by gpiod_line_consumer. The second thread may retrieve an incorrect consumer name.
On the other hand gpiod_line_event_wait_bulk is a blocking call which makes it a good candidate for calling in a separate thread. This however would require thread safety.
Hi,
I currently trying to read the DHT11 sensor, connected via GPIO to a Raspberry Pi 3 B. The sensor requires the line to be set to 0 for at least 18ms and then 1 again. Then, the sensor will wait for 50us to pull the line to 0 again, then up after 50 us, and start sending data.
I would like to catch the two edge events, but I'm not able to switch the line direction faster enough, and I'm missing the first edge. The code I'm using is the following:
if(gpiod_line_request_output(line, "temp output", 0) < 0)
{
perror("gpiod_line_request_output()");
return 1;
}
nanosleep(&dt, NULL);
clock_gettime(CLOCK_MONOTONIC, &tic);
gpiod_line_release(line);
if(gpiod_line_request_input(line, "temp reader"))
{
perror("gpiod_line_request_input()");
return 1;
}
clock_gettime(CLOCK_MONOTONIC, &toc);
if(toc.tv_sec > tic.tv_sec)
{
toc.tv_sec -= tic.tv_sec;
toc.tv_nsec += 1000000000;
}
toc.tv_nsec -= tic.tv_nsec;
printf("Change direction took %ld ns\n", toc.tv_nsec);Which leads to the following measurements:
% repeat 10 ./temp gpiochip0
Change direction took 61353 ns
Change direction took 65208 ns
Change direction took 63280 ns
Change direction took 69374 ns
Change direction took 63802 ns
Change direction took 86145 ns
Change direction took 72603 ns
Change direction took 58957 ns
Change direction took 70103 ns
Change direction took 64322 ns
Is there a faster way to change the line direction using the current exposed API calls? And if not, is this a useful use case to be considered maybe in something like (of an already requested line):
gpiod_line_set_direction(struct gpiod_line *line, int direction, int default_val)Best regards,
Rodrigo.
Some interfaces in the library now seem to have been designed badly. Below is the list of changes that will potentially be introduced in v1.0.
gpiod_line_event_release(): we can check if a line is currently free, reserved for events or for setting/reading values, so we don't need a separate release functiongpiod_line_is_reserved(): this name implies that the function checks if someone else owns the line, while in reality it checks if the caller is the ownerAre there any bindings available to Qt with its signal/slot mechanism?
Hello!
Thanks for the nice work.
We are trying to install libgpiod with its Python bindings on a Beagle Bone Black – a ARMv7 32 bit SBC. The distribution is a Debian Stretch 9.9, Kernel version is 4.14.93-bone-rt-r17.
Installed Python versions are 3.5 and 3.6.
We tried to compile and run the lib for both the system Python (3.5) and in a virtualenv with Python3.6.
./autogen.sh --enable-tools=yes --prefix=<install path> --enable-bindings-python CFLAGS="-fPIC"
make
make install
ldconfig
Everything looks fine, configuration doesn't report any issue and also building stages. But as soon as we load a Python REPL and import gpiod we get the following exception:
ImportError: /usr/local/lib/python3.5/dist-packages/gpiod.so: unexpected reloc type 0x03
Anyone gets the same problem? Do you have any clue why it happens? Any suggestion?
Hello,
HW: RPi 3B, OS: ArchLinux, Kernel: 6.1.69-1-rpi-ARCH, Python: 3.11, gpiod: 2.1.3 from pypi.org
I'm porting some of my python scripts to libgpiod and I've run into a problem with request.reconfigure_lines method. Instead of succeeding, it raises ValueError with (22, 'Invalid argument').
The script basically opens 7 lines (some inputs, some outputs) in one request, does some work, and at the end wants to switch all output lines back to inputs so HW stops driving them. Both config dictionaries (first for request_lines, second for reconfigure_lines) are constructed dynamically from different metadata, and what I believe to be important, are likely to be in different order. When I pass the same dict to both methods, there's no exception (but obviously nothing changes).
Toy reproducer attached - it works reliably cause nowadays python dicts remember insertion order. Before Python 3.6 (or 3.7?) it would fail randomly. I've also included a third dict in the reproducer - with just one line to be reconfigured - this also fails, which I find counterintuitive, cause other functions like get/set values can operate on a subset of requested lines.
Can this be fixed inside gpiod or is the user expected to take care of sorting config dicts somehow?
Hi,
I'm attempting to update my C++ code to align with the new version of libgpiod (> 2.0). However, I'm facing difficulties installing libgpiod-dev using the provided command:
sudo apt-get install libgpiod-dev
The package available at https://packages.debian.org/unstable/libgpiod-dev is currently at version 1.6.3-1+b3.
Is it feasible to include a new package for version 2.0 or later?
Best regards.
Consider the following sequence of operations:
% x=DIG7_PU_PD
% gpioinfo | grep $x
line 7: "DIG7_PU_PD" unused input active-high
% gpiofind $x
gpiochip2 7
% gpioset gpiochip2 7=0
% gpioget gpiochip2 7
0
% gpioset gpiochip2 7=1
% gpioget gpiochip2 7
1
% gpioinfo | grep $x
line 7: "DIG7_PU_PD" unused input active-high
I admit that line is requested only for an operation to be made, but the state of it apparently left output. The last info dump is simple wrong.
It might be kernel GPIO library error, though I don't have time right now to go deeper into it.
UPDATE. I think a simple workaround might be to invent gpiorequest and gpiorelease binaries to help with it. and update tools accordingly (like adding switch --requested to bypass request-release cycle while keeping backward compatibility).
Some inline functions in gpiod.h use designated initializers which is a C99 feature. This would lead to problems for external programs who might be stricter regarding the C standard. Pull all functions using designated initializers into core.c.
Thanks for these utilities; I switched our embedded home automation systems from sysfs pretty easily using them.
I did make two changes:
In gpioset.c, I removed the getchar() in function wait_for_enter. Since the command is called from a script, there was no need for the interaction. My script maintains the state of the GPIO pins used so that they can be restored across reboots, and there is no concurrent use.
In gpiomon.c, I changed the initialization of do_run from true to false. My scripts use a poll loop, so I just need to see the state change:
# Clear any pending state updates
state="$(/usr/local/bin/gpiomon gpiochip0 230)"
while [ "$state" != "" ]; do
state="$(/usr/local/bin/gpiomon gpiochip0 230)"
done
# Wait for state change
state="$(/usr/local/bin/gpiomon gpiochip0 230)"
while [ "$state" == "" ]; do
state="$(/usr/local/bin/gpiomon gpiochip0 230)"
done
I think both of those changes might be generically useful, and options on the commands to change their operation would make it easier than patching.
When there are more than 99 GPIO lines on a chip, the formatting breaks:
line 93: unnamed unused input active-high
line 94: unnamed unused input active-high
line 95: unnamed unused input active-high
line 96: unnamed unused input active-high
line 97: unnamed unused input active-high
line 98: unnamed unused input active-high
line 99: unnamed unused input active-high
line 100: unnamed unused input active-high
line 101: unnamed unused input active-high
line 102: unnamed unused input active-high
line 103: unnamed unused input active-high
line 104: unnamed unused input active-high
line 105: unnamed unused input active-high
line 106: unnamed unused input active-high
line 107: unnamed unused input active-high
line 108: unnamed unused input active-high
line 109: unnamed unused input active-high
Hi,
I'm trying to learn how to use gpiod on BeagleBone with Debian Stretch.
When I make a GPIO pin output, I want to read its state to know if it is 0 or 1. But doing so, I always get this error:
gpioget: error reading GPIO values: Device or resource busy
Is there any way to do so?
Problem: gpioset turns a pin off when it should turn the pin on.
Expected behavior: gpioset gpiochip2 9=1 should turn on gpio2[9]
Observed behavior: gpioset gpiochip2 9=1 turns off gpio2[9] and unexports it
I'm new to libgpiod, so maybe I'm misunderstanding the API?
Details:
$ config-pin P8_44 1 # This turns P8_44 on as expected
$ gpioset gpiochip2 9=1 # Should turn on gpio2[9], i.e. P8_44, but turns it off.
$ config-pin P8_44 1 # Now config-pin can't access the pin???
WARNING: GPIO pin not exported, cannot set direction or value!
$ gpioset --mode=wait gpiochip2 9=1 # This turns the pin on until I hit ^C ?
This isn't specific to P8_44; for instance gpioset gpiochip2 7=1 will mess up P8_46 (gpio2[7]). This also happens even if I don't use config-pin, so it's not config-pin messing things up.
Version: Linux beaglebone 4.14.71-ti-r80 #1 SMP PREEMPT Fri Oct 5 23:50:11 UTC 2018 armv7l GNU/Linux
I've looked around for any tests or experiences related to the latency, jitter, and accuracy related to the edge event timstamps in libgpiod, but have been unable to find anything. How does it compare to the timestamps set by the pps-gpio kernel module, which is based around interrupts?
Another point of comparison is the pps-gpio-poll out-of-tree kernel module. It provides a PPS device based on busy-waiting and polling of the GPIO. According to the author, which is the maintainer of chrony, this approach is more accurate and have less jitter than the interrupt-based pps-gpio (albeit with more CPU usage).
Any insight is appreciated, even if not backed by real data.
Hi,
while it's true that starting enums with 1 might help with debugging, this is a major API change which is quite unfortunate for libgpiod binding in other languages, or any other code which needs to maintain ABI compatibility. At the very least this requires a soname change.
IMHO the advantages aren't worth the hassle … not at this stage.
Implement python bindings for libgpiod.
Create a common structure filled by each tool which would be passed to a common routine printing the help text from tools-common.c.
I am working to upgrade a sysfs event polling rising edge detection implementation to libgpiod to make use of the kernel event timestamping.
In testing I found that the gpiod is not able to detect rising edge's on my pins for some reason. I verified this was not a usage issue in my code by testing with gpiomon in command line. gpiomon was also not detecting rising edges, although it did detect falling edges.
Relevant info:
Device Tree is a combination of these:
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.19.x/src/arm/am33xx.dtsi
https://github.com/RobertCNelson/dtb-rebuilder/blob/4.19.x/src/arm/am335x-osd335x-common.dtsi
and this:
&am33xx_pinmux {
ecap0_pins_default: ecap0_pins_default {
pinctrl-single,pins = <
AM33XX_IOPAD(0x964, PIN_INPUT | MUX_MODE0) /* gpio0[7] */
>;
};
gpio3_pins_default: gpio3_pins_default {
pinctrl-single,pins = <
AM33XX_IOPAD(0x99c, PIN_INPUT | MUX_MODE7) /* gpio3[17] */
>;
};
};
When I run gpiomon on one pin I get both rising and falling edges:
gpiomon gpiochip0 7
event: RISING EDGE offset: 7 timestamp: [1709072918.200972377]
event: FALLING EDGE offset: 7 timestamp: [1709072918.700979793]
event: RISING EDGE offset: 7 timestamp: [1709072919.200997043]
event: FALLING EDGE offset: 7 timestamp: [1709072919.701002002]
event: RISING EDGE offset: 7 timestamp: [1709072920.201015460]
event: FALLING EDGE offset: 7 timestamp: [1709072920.701029335]
event: RISING EDGE offset: 7 timestamp: [1709072921.201066377]
But When I run it on another I get only falling edges:
gpiomon gpiochip3 17
event: FALLING EDGE offset: 17 timestamp: [1709073108.897098295]
event: FALLING EDGE offset: 17 timestamp: [1709073109.897153795]
event: FALLING EDGE offset: 17 timestamp: [1709073110.897172545]
event: FALLING EDGE offset: 17 timestamp: [1709073111.897198629]
event: FALLING EDGE offset: 17 timestamp: [1709073112.897222629]
event: FALLING EDGE offset: 17 timestamp: [1709073113.897253671]
/sys/kernel/debug/gpio contents:
gpiochip0: GPIOs 0-31, parent: platform/44e07000.gpio, gpio-0-31:
gpio-7 (ECAP0_IN_PWM0_OUT |gpiomon ) in hi IRQ
gpiochip3: GPIOs 96-127, parent: platform/481ae000.gpio, gpio-96-127:
gpio-113 (MCASP0_AHCLKR |gpiomon ) in lo IRQ
Running a sysfs based monitor on either pin is able to detect both rising and falling edges.
I suspect this is either a kernel issue in my kernel version or a device tree issue, but I can't figure it out. The part that really throws me is that the sysfs based gpio event polling works fine on the same pins.
Note: I realize it would be great to update the kernel/OS versions, but unless I can only do that if I have a specific fix to point at to move those updates up on the development pipeline.
I'm trying to use python bindings to libgpiod-1.2 on Raspberry Pi Model B Rev 2. Looks like pull-up/ pull-down resistors can't be enabled? Could you recommend any way to do that? Or should I configure that with device tree?
Hello Bartosz, is there any way to organize GPIOs into bus? Instead of operating the bits per GPIO - organize, let's say, 8 GPIOs into the bus and pass 8-bit argument to the reading/writing calls? I can not find such functionality for gpiod as well as for ioctl access (however ioctl allows multiple lines). Does not sound elegant (and probably efficient?) splitting a bus into separate bits and pass 8 bytes for processing.
I patched my local buildroot to enable the C++ bindings:
diff --git a/package/libgpiod/libgpiod.mk b/package/libgpiod/libgpiod.mk
index 598adcc599..68b1166a5d 100644
--- a/package/libgpiod/libgpiod.mk
+++ b/package/libgpiod/libgpiod.mk
@@ -19,4 +19,8 @@ else
LIBGPIOD_CONF_OPTS += --disable-tools
endif
+ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
+LIBGPIOD_CONF_OPTS += --enable-bindings-cxx
+endif
+
$(eval $(autotools-package))and asked it to use my local checkout (commit a5ee3d7, current master) via local.mk:
builddir $ grep GPIO local.mk
LIBGPIOD_OVERRIDE_SRCDIR = /path/to/my/checkout/of/libgpiod
I also had to run ./autogen.sh in the git checkout prior to letting Buildroot work there. That's expected.
The build fails:
jkt@kolibrik ~/work/prog/_build/br-cfb $ rm -rf build/libgpiod*
jkt@kolibrik ~/work/prog/_build/br-cfb $ make libgpiod
umask 0022 && make -C /home/jkt/work/cesnet/gerrit/github/buildroot/buildroot O=/home/jkt/work/prog/_build/br-cfb/. libgpiod
>>> libgpiod custom Syncing from source dir /home/jkt/work/cesnet/gerrit/github/brgl/libgpiod
rsync -au --chmod=u=rwX,go=rX --exclude .svn --exclude .git --exclude .hg --exclude .bzr --exclude CVS /home/jkt/work/cesnet/gerrit/github/brgl/libgpiod/ /home/jkt/work/prog/_build/br-cfb/build/libgpiod-custom
>>> libgpiod custom Configuring
(cd /home/jkt/work/prog/_build/br-cfb/build/libgpiod-custom/ && rm -rf config.cache && PATH="/home/jkt/work/prog/_build/br-cfb/host/bin:/home/jkt/work/prog/_build/br-cfb/host/sbin:/home/jkt/.local/bin:/home/jkt/bin/:/opt/qtc/bin:/opt/darktable/bin:/home/jkt/.local/bin:/home/jkt/bin/:/opt/qtc/bin:/opt/darktable/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/usr/lib/llvm/4/bin:/usr/games/bin" AR="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ar" AS="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-as" LD="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld" NM="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-nm" CC="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc" GCC="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc" CPP="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-cpp" CXX="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++" FC="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gfortran" F77="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gfortran" RANLIB="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ranlib" READELF="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-readelf" STRIP="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-strip" OBJCOPY="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-objcopy" OBJDUMP="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-objdump" AR_FOR_BUILD="/usr/bin/ar" AS_FOR_BUILD="/usr/bin/as" CC_FOR_BUILD="/usr/bin/gcc" GCC_FOR_BUILD="/usr/bin/gcc" CXX_FOR_BUILD="/usr/bin/g++" LD_FOR_BUILD="/usr/bin/ld" CPPFLAGS_FOR_BUILD="-I/home/jkt/work/prog/_build/br-cfb/host/include" CFLAGS_FOR_BUILD="-O2 -I/home/jkt/work/prog/_build/br-cfb/host/include" CXXFLAGS_FOR_BUILD="-O2 -I/home/jkt/work/prog/_build/br-cfb/host/include" LDFLAGS_FOR_BUILD="-L/home/jkt/work/prog/_build/br-cfb/host/lib -Wl,-rpath,/home/jkt/work/prog/_build/br-cfb/host/lib" FCFLAGS_FOR_BUILD="" DEFAULT_ASSEMBLER="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-as" DEFAULT_LINKER="/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld" CPPFLAGS="-fstack-protector-strong -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" CFLAGS="-fstack-protector-strong -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os " CXXFLAGS="-fstack-protector-strong -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os " LDFLAGS="" FCFLAGS=" -Os " FFLAGS=" -Os " PKG_CONFIG="/home/jkt/work/prog/_build/br-cfb/host/bin/pkg-config" STAGING_DIR="/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot" INTLTOOL_PERL=/usr/bin/perl ac_cv_lbl_unaligned_fail=yes ac_cv_func_mmap_fixed_mapped=yes ac_cv_func_memcmp_working=yes ac_cv_have_decl_malloc=yes gl_cv_func_malloc_0_nonnull=yes ac_cv_func_malloc_0_nonnull=yes ac_cv_func_calloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes lt_cv_sys_lib_search_path_spec="" ac_cv_c_bigendian=no CONFIG_SITE=/dev/null ./configure --target=arm-buildroot-linux-gnueabihf --host=arm-buildroot-linux-gnueabihf --build=x86_64-pc-linux-gnu --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --localstatedir=/var --program-prefix="" --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation --with-xmlto=no --with-fop=no --enable-ipv6 --disable-nls --disable-static --enable-shared --enable-tools --enable-bindings-cxx )
configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --enable-ipv6, --disable-nls
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-buildroot-linux-gnueabihf-strip... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for arm-buildroot-linux-gnueabihf-gcc... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc accepts -g... yes
checking for /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc option to accept ISO C89... none needed
checking whether /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc understands -c and -o together... yes
checking dependency style of /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc... gcc3
checking for arm-buildroot-linux-gnueabihf-ar... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ar
checking the archiver (/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ar) interface... ar
checking for arm-buildroot-linux-gnueabihf-gcc... (cached) /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc accepts -g... (cached) yes
checking for /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc option to accept ISO C89... (cached) none needed
checking whether /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc understands -c and -o together... (cached) yes
checking dependency style of /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc... (cached) gcc3
checking whether we are using the GNU C++ compiler... yes
checking whether /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ accepts -g... yes
checking dependency style of /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++... gcc3
checking build system type... x86_64-pc-linux-gnu
checking host system type... arm-buildroot-linux-gnueabihf
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld
checking if the linker (/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-nm
checking the name lister (/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to arm-buildroot-linux-gnueabihf format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld option to reload object files... -r
checking for arm-buildroot-linux-gnueabihf-objdump... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-objdump
checking how to recognize dependent libraries... pass_all
checking for arm-buildroot-linux-gnueabihf-dlltool... no
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for arm-buildroot-linux-gnueabihf-ar... (cached) /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ar
checking for archiver @FILE support... @
checking for arm-buildroot-linux-gnueabihf-strip... (cached) /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-strip
checking for arm-buildroot-linux-gnueabihf-ranlib... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ranlib
checking command to parse /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-nm output from /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for arm-buildroot-linux-gnueabihf-mt... no
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-cpp
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc supports -fno-rtti -fno-exceptions... no
checking for /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc option to produce PIC... -fPIC -DPIC
checking if /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc PIC flag -fPIC -DPIC works... yes
checking if /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc static flag -static works... yes
checking if /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc supports -c -o file.o... yes
checking if /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc supports -c -o file.o... (cached) yes
checking whether the /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-gcc linker (/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ -E
checking for ld used by /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++... /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld
checking if the linker (/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld) is GNU ld... yes
checking whether the /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ linker (/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld) supports shared libraries... yes
checking for /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ option to produce PIC... -fPIC -DPIC
checking if /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ PIC flag -fPIC -DPIC works... yes
checking if /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ static flag -static works... yes
checking if /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ supports -c -o file.o... yes
checking if /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ supports -c -o file.o... (cached) yes
checking whether the /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ linker (/home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-ld) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for ANSI C header files... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... (cached) yes
checking for ioctl... yes
checking for asprintf... yes
checking for scandir... yes
checking for alphasort... yes
checking for ppoll... yes
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking linux/gpio.h usability... yes
checking linux/gpio.h presence... yes
checking for linux/gpio.h... yes
checking for basename... yes
checking for daemon... yes
checking for signalfd... yes
checking sys/signalfd.h usability... yes
checking sys/signalfd.h presence... yes
checking for sys/signalfd.h... yes
checking whether /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ supports C++11 features by default... yes
checking for doxygen... true
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating libgpiod.pc
config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating src/Makefile
config.status: creating src/lib/Makefile
config.status: creating src/tools/Makefile
config.status: creating tests/Makefile
config.status: creating bindings/Makefile
config.status: creating bindings/cxx/Makefile
config.status: creating bindings/cxx/examples/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --enable-ipv6, --disable-nls
>>> libgpiod custom Building
PATH="/home/jkt/work/prog/_build/br-cfb/host/bin:/home/jkt/work/prog/_build/br-cfb/host/sbin:/home/jkt/.local/bin:/home/jkt/bin/:/opt/qtc/bin:/opt/darktable/bin:/home/jkt/.local/bin:/home/jkt/bin/:/opt/qtc/bin:/opt/darktable/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/usr/lib/llvm/4/bin:/usr/games/bin" /usr/bin/make -j5 -C /home/jkt/work/prog/_build/br-cfb/build/libgpiod-custom/
/usr/bin/make all-recursive
Making all in include
make[4]: Nothing to be done for 'all'.
Making all in src
Making all in lib
CC libgpiod_la-core.lo
CC libgpiod_la-ctxless.lo
CC libgpiod_la-helpers.lo
CC libgpiod_la-misc.lo
CC libgpiod_la-iter.lo
CCLD libgpiod.la
Making all in tools
CC tools-common.lo
CC gpiodetect.o
CC gpioget.o
CC gpioset.o
CC gpioinfo.o
CC gpiomon.o
CC gpiofind.o
CCLD libtools-common.la
CCLD gpioinfo
CCLD gpioset
CCLD gpiodetect
CCLD gpioget
CCLD gpiomon
CCLD gpiofind
make[5]: Nothing to be done for 'all-am'.
Making all in bindings
Making all in .
make[5]: Nothing to be done for 'all-am'.
Making all in cxx
Making all in .
CXX libgpiodcxx_la-chip.lo
CXX libgpiodcxx_la-iter.lo
CXX libgpiodcxx_la-line.lo
CXX libgpiodcxx_la-line_bulk.lo
CXXLD libgpiodcxx.la
Making all in examples
make[6]: Nothing to be done for 'all'.
>>> libgpiod custom Installing to staging directory
PATH="/home/jkt/work/prog/_build/br-cfb/host/bin:/home/jkt/work/prog/_build/br-cfb/host/sbin:/home/jkt/.local/bin:/home/jkt/bin/:/opt/qtc/bin:/opt/darktable/bin:/home/jkt/.local/bin:/home/jkt/bin/:/opt/qtc/bin:/opt/darktable/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/usr/lib/llvm/4/bin:/usr/games/bin" /usr/bin/make -j5 DESTDIR=/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot install -C /home/jkt/work/prog/_build/br-cfb/build/libgpiod-custom/
Making install in include
make[4]: Nothing to be done for 'install-exec-am'.
/bin/mkdir -p '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include'
/usr/bin/install -c -m 644 gpiod.h '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include'
Making install in src
Making install in lib
make[5]: Nothing to be done for 'install-data-am'.
/bin/mkdir -p '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib'
/bin/sh ../../libtool --mode=install /usr/bin/install -c libgpiod.la '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib'
libtool: install: /usr/bin/install -c .libs/libgpiod.so.1.1.0 /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgpiod.so.1.1.0
libtool: install: (cd /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib && { ln -s -f libgpiod.so.1.1.0 libgpiod.so.1 || { rm -f libgpiod.so.1 && ln -s libgpiod.so.1.1.0 libgpiod.so.1; }; })
libtool: install: (cd /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib && { ln -s -f libgpiod.so.1.1.0 libgpiod.so || { rm -f libgpiod.so && ln -s libgpiod.so.1.1.0 libgpiod.so; }; })
libtool: install: /usr/bin/install -c .libs/libgpiod.lai /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libgpiod.la
libtool: warning: remember to run 'libtool --finish /usr/lib'
Making install in tools
make[5]: Nothing to be done for 'install-data-am'.
/bin/mkdir -p '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/bin'
/bin/sh ../../libtool --mode=install /usr/bin/install -c gpiodetect gpioinfo gpioget gpioset gpiomon gpiofind '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/bin'
libtool: warning: '../../src/lib/libgpiod.la' has not been installed in '/usr/lib'
libtool: install: /usr/bin/install -c .libs/gpiodetect /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/bin/gpiodetect
libtool: warning: '../../src/lib/libgpiod.la' has not been installed in '/usr/lib'
libtool: install: /usr/bin/install -c .libs/gpioinfo /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/bin/gpioinfo
libtool: warning: '../../src/lib/libgpiod.la' has not been installed in '/usr/lib'
libtool: install: /usr/bin/install -c .libs/gpioget /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/bin/gpioget
libtool: warning: '../../src/lib/libgpiod.la' has not been installed in '/usr/lib'
libtool: install: /usr/bin/install -c .libs/gpioset /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/bin/gpioset
libtool: warning: '../../src/lib/libgpiod.la' has not been installed in '/usr/lib'
libtool: install: /usr/bin/install -c .libs/gpiomon /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/bin/gpiomon
libtool: warning: '../../src/lib/libgpiod.la' has not been installed in '/usr/lib'
libtool: install: /usr/bin/install -c .libs/gpiofind /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/bin/gpiofind
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
Making install in bindings
Making install in .
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
Making install in cxx
Making install in .
/bin/mkdir -p '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib'
/bin/mkdir -p '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include'
/bin/sh ../../libtool --mode=install /usr/bin/install -c libgpiodcxx.la '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib'
/usr/bin/install -c -m 644 gpiod.hpp '/home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include'
libtool: warning: relinking 'libgpiodcxx.la'
libtool: install: (cd /home/jkt/work/prog/_build/br-cfb/build/libgpiod-custom/bindings/cxx; /bin/sh "/home/jkt/work/prog/_build/br-cfb/build/libgpiod-custom/libtool" --silent --tag CXX --mode=relink /home/jkt/work/prog/_build/br-cfb/host/bin/arm-linux-gnueabihf-g++ -fstack-protector-strong -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -version-number 1:1 -lgpiod -L../../src/lib -o libgpiodcxx.la -rpath /usr/lib libgpiodcxx_la-chip.lo libgpiodcxx_la-iter.lo libgpiodcxx_la-line.lo libgpiodcxx_la-line_bulk.lo -inst-prefix-dir /home/jkt/work/prog/_build/br-cfb/host/arm-buildroot-linux-gnueabihf/sysroot)
arm-linux-gnueabihf-g++: ERROR: unsafe header/library path used in cross-compilation: '-L/usr/lib'
libtool: error: error: relink 'libgpiodcxx.la' with the above command before installing it
Makefile:438: recipe for target 'install-libLTLIBRARIES' failed
make[6]: *** [install-libLTLIBRARIES] Error 1
Makefile:733: recipe for target 'install-am' failed
make[5]: *** [install-am] Error 2
Makefile:572: recipe for target 'install-recursive' failed
make[4]: *** [install-recursive] Error 1
Makefile:374: recipe for target 'install-recursive' failed
make[3]: *** [install-recursive] Error 1
Makefile:486: recipe for target 'install-recursive' failed
make[2]: *** [install-recursive] Error 1
package/pkg-generic.mk:286: recipe for target '/home/jkt/work/prog/_build/br-cfb/build/libgpiod-custom/.stamp_staging_installed' failed
make[1]: *** [/home/jkt/work/prog/_build/br-cfb/build/libgpiod-custom/.stamp_staging_installed] Error 2
Makefile:16: recipe for target '_all' failed
make: *** [_all] Error 2
The code for repr of LineSettings is missing commas to separate the arguments
Current
LineSettings(direction={}, edge_detection={} bias={} drive={} active_low={} debounce_period={} event_clock={} output_value={})
Correct:
LineSettings(direction={}, edge_detection={}, bias={}, drive={}, active_low={}, debounce_period={}, event_clock={}, output_value={})
A suitable test would be
test_settings = LineSettings(....)
assert test_settings == eval(test_settings.__repr__())
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.