GTest now requires at least c++14 and this line caused compilation
failures while working fine without it.
Signed-off-by: Alex T <alext.mkrs@gmail.com>
* Add copyright headers to XML and YAML files
* Add (tm) to the first mention of Eclipse MRAA in the README
* Rename COPYING to LICENSE.md per the standard Eclipse requirement
Signed-off-by: Alex T <alext.mkrs@gmail.com>
This fixes the following warning shown while configuring:
[cmake] CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
[cmake] Compatibility with CMake < 3.10 will be removed from a future version of
[cmake] CMake.
We don't have a clearly defined supported distro/versions list, so I
took Ubuntu 22.04 as arguably the oldest one we'd want to support for
the reference point. It has CMake 3.22, released in July 2022.
Signed-off-by: Alex T <alext.mkrs@gmail.com>
This fixes the following compilation warnings:
mraa/src/src/mock/mock_board.c: In function ‘mraa_mock_board’:
mraa/src/src/mock/mock_board.c:156:5: warning: ‘strncpy’ output truncated before terminating nul copying 8 bytes from a string of the same length [-Wstringop-truncation]
156 | strncpy(b->pins[pos].name, "SPI0MOSI", 8);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mraa/src/src/mock/mock_board.c:162:5: warning: ‘strncpy’ output truncated before terminating nul copying 8 bytes from a string of the same length [-Wstringop-truncation]
162 | strncpy(b->pins[pos].name, "SPI0MISO", 8);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mraa/src/src/mock/mock_board.c:168:5: warning: ‘strncpy’ output truncated before terminating nul copying 8 bytes from a string of the same length [-Wstringop-truncation]
168 | strncpy(b->pins[pos].name, "SPI0SCLK", 8);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alex T <alext.mkrs@gmail.com>
When compiling mraa on Debian 13, the following error occurs:
```
/usr/include/node/node.h:696:8: error: ‘optional’ in namespace ‘std’ does not name a template type
696 | std::optional<std::string> builder_script_path;
| ^~~~~~~~
/usr/include/node/node.h:696:3: note: ‘std::optional’ is only available from C++17 onwards
696 | std::optional<std::string> builder_script_path;
| ^~~
```
Root cause: Node.js version on Debian 13 is 20+, which requires C++17 feature support.
Signed-off-by: Chun Jiao Zhao <chunjiao.zhao@siemens.com>
PyEval_InitThreads and PyEval_CallObject were deprecated since
Python 3.9 and removed in Python 3.12+ and 3.13+ respectively.
These APIs are unavailable on Debian 13 which ships Python 3.13.
Refer to: https://github.com/eclipse/mraa/issues/1135
Signed-off-by: Chun Jiao Zhao <chunjiao.zhao@siemens.com>
in OE we use i686 for qemux86 and this results in
-- INFO - Target arch is i686
CMake Error at CMakeLists.txt:191 (message):
Only x86, arm, mips, PERIPHERALMAN and mock platforms currently supported
So using a wildcard helps in using any x86 arch
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Musl exposes this problem where PATH_MAX is used but limits.h is not
included, it works with glibc perhaps due to limits.h being indirectly
included by another system header.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
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>
