A simple GPIO, no muxing needed, no pulling supported. Therefore, reject
any mode changes that request pull up/down, ignore the others.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This patch introuduce iot2050 platform support, it is the port from
meta-iot2050 layer.
Based on original patch by Le Jin.
Signed-off-by: Le Jin <le.jin@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Ivan Mikhaylov <ivan.mikhaylov@siemens.com>
This allows to full mux structures which still need the sysfs GPIO
numbers. In combination with mraa_find_gpio_line_by_name, this allows
for platform setup that is independent of the gpiochip probing order.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This makes the retrieval robust against chips being reordered during
boot. The results can be used to fill out mraa_pin_t while initializing
a board.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Add mux_init_reg interface with different mux modes for GPIO, UART, SPI,
I2C, PWM, AIO.
Signed-off-by: Le Jin <le.jin@siemens.com>
Signed-off-by: Ivan Mikhaylov <ivan.mikhaylov@siemens.com>
In swig 4.1.0, the complicated handling of "SWIG_V8_VERSION" has been cleaned up a bit. I made the same changes as in this swig.
Signed-off-by: Hirokazu MORIKAWA <morikw2@gmail.com>
*cinfos in mraa_get_chip_infos is not set in case of
mraa_get_chip_info_by_name failure which happens on access of /dev/gpiochip*
files which leads to memory free by invalid pointer in *cinfos.
As example, it can be easy recreated with non-root run of mraa-gpio:
test@iot2050-debian:~$ mraa-gpio
free(): invalid pointer
Aborted
Signed-off-by: Ivan Mikhaylov <ivan.mikhaylov@siemens.com>
The warning is aiming at external use, not our own one. Silence the
latter by adding an internal service that the deprecated function calls
and use that service in the remaining mraa use cases.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
CMake automatically pulls CMAKE_C_FLAGS and CMAKE_CXX_FLAGS, according
to the source file. Adding CMAKE_C_FLAGS unconditionally only raises
cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit’ is not valid for C++
cc1plus: warning: ‘-Werror=’ argument ‘-Werror=missing-parameter-type’ is not valid for C++
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Truncation warnings are default-on with many gcc-10 packages but the
module is fine with the potential truncations of sysfs paths as they
are.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
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>
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>
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>
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>
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>
