The recommended config for upstream kernels (arm64
defconfig) on the Radxa "mainline" kernel Wiki
does not include GPIO sysfs support, so libmraa
applications and utilies don't work out of the
box. This change marks the board as supporting the
GPIO character device interface and fixes the
group and line number assignments such that it
actually works. Performance is also noticeably
better with the chardev path.
I tested this by using mraa-gpio to toggle various
pins on the 40-pin header with a multimeter
attached, and with a program I have that that
toggles 8 GPIO pins at the same time to upload
data to another system using a parallel protocol.
On upstream/mainline kernels, chardev support is
now used. On the older 4.4 kernels from Radxa,
chardev support is not available and libmraa
gracefully falls back to sysfs.
Note another significant difference compared to
the Radxa kernels in upstream kernels is the
default devicetree must be tweaked to disable the
'i2s1' device in order to use GPIO pins 12, 35,
36, 38, and 40 via libmraa. For example, I
appended the following section:
&i2s1 {
status = "disabled";
};
to arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4b.dts
to accomplish this.
Signed-off-by: James Jones <linux@theinnocuous.com>
mraa_aio_set_bit() changes value_bit, so the calculations of
shifter_value and max_analog_value become outdated. Move their
initialization to mraa_aio_set_bit and call that function from
mraa_aio_init instead.
Based on original patch by Le Jin.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
When a GPIO controlled via sysfs is set again to output mode, the kernel
also sets the value to 0. This can cause spurious output or mux changes,
e.g. when calling "mraa-gpio set <n> 1" for a pin that was already set.
Avoid this by checking the current direction, only writing it when
actually needed.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This is needed for bindings to languages which perform implicit and lazy
object cleanups. The explicit close methods allow to release resources
when they are no longer required, permitting deterministic reuse. One
example is node-red-node-intel-gpio which will use the new calls on node
closing.
Fixes#1044.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
The structure returned by readdir is may be statically allocated.
Keeping a pointer to it is broken.
The LED path is generally not a directory, it's a link to a directory.
And even if it were a directory, that would tell nothing about the
caller's access permissions.
And then there is a lot of duplication between mraa_led_init and
mraa_led_init_raw.
This addresses that all.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Rather than updating IXON/IXOFF in termios, mraa_uart_set_flowcontrol
was incorrectly issuing a stop or start character on mode changes. This
lead to spurious transmission in setups that actually wanted to disable
software flow control. And it prevented enabling it (which could have
been checked also by reading back the state via mraa_uart_settings).
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This removes Python 2 package generation from the project to encourage safer development with Python 3 instead. Documentation for the generated modules switched to Python 3. Default interpreter is now Python 3 but can be overridden if needed for running the tests only on older environments.
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
Disables node.js wrapper generation and builds by default as latest versions of node.js do not build with latest SWIG. An official patch for SWIG should revert this, community pointed out a workaround exists already but requires manual patching. This may affect packaging jobs and builders not using BUILDSWIGNODE explicitly, e.g. NPM and external to the project.
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
C++ is a mandatory dependency since version 1.4.0 and
122cab1f1e
As a result, build on embedded toolchains that do not support C++ fails
on:
CMake Error at CMakeLists.txt:2 (project):
The CMAKE_CXX_COMPILER:
/home/naourr/work/instance-1/output-1/per-package/mraa/host/bin/arm-linux-g++
is not a full path to an existing compiler tool.
Fixes:
- http://autobuild.buildroot.org/results/31086422e03611c16ab59c4418e3669b580bc0c0
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
No longer supported by sonar scans, the preview feature is now disabled and internal PRs from project contributors are also scanned for vulnerabilities/bugs as part of CI
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
For testing purposes it should be possible to share .deb packages across a variety of Debian builds or .rpm packages across systems that have dnf/yum available
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
Removed installing for node.js section as latest versions of node have issues building until Swig is patched. Also make it clear some mainstream Linux don't have binaries available in official repos.
Signed-off-by: Mihai Tudor Panu <mihai.tudor.panu@intel.com>
e.g.:
cv2 import at the beginning throws the error:
import cv2
import mraa
import time
...
Error:
ValueError: Error initialising PWM on pin
Signed-off-by: Brian Lee <brian@vamrs.com>
After rebase UP Xtreme supported platform enum value was changed
to 24 in types.h, this commit updates the enum value in types.hpp
to this value.
Signed-off-by: Michael Campion <michael.campion@emutex.com>
UP Xtreme is based on the Intel(R) Core(TM) i3/i5/i7 Whiskey Lake SoCs.
The UP Xtreme presents one Raspberry Pi compatible HAT connector.
This implementaion supports i2c, spi, uart, adc and gpio through the
40pin HAT connector.
Gpio chardev capabilities have been disabled in this implementation. When
gpio chardev capabilities are enabled an input becomes unreadable after an
isr has been registered to the pin. See here for details:
https://github.com/intel-iot-devkit/mraa/issues/937
Tested on UP Xtreme, with UP Board Linux kernel 5.0.0
Features tested: gpio, gpio interrupts, i2c, spi, adc and uart.
Signed-off-by: Michael Campion <michael.campion@emutex.com>
This commit introduces mraa_gpio_init_by_name API for initializing
a GPIO by its line name provided by the kernel. This feature depends
on the GPIO chardev support and also the line names present in devicetree
or board files. Accessing GPIO using its line name, removes the dependency
from MRAA specific pin mapping and provides a cleaner way to access GPIOs.
This will solve the issue created by an external gpiochip probing before
the SoC's internal gpio controller and thereby making the MRAA pin mapping
wrong.
Currently, this API only supports initializing a single GPIO at a time.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
