The native CAN implementation relies on the underlying OS to implement
CAN, so we can leave handling the nitty-gritty details such as the loop
delay to the underlying implementation.
`pid_t` is provided e.g. by `<sys/types.h>`. It seems that on glibc,
`<stdlib.h>` will also provide `pid_t`. But this way it should work on
both musl and glibc.
The real_read() function will block the thread but won't preempt it.
That means all other thereads on the same (or higher) priority level
are blocked as RIOT still consideres the thread that called stdio_read()
as running.
Use async_read/isrpipe to properly block the thread when reading from
stdin.
As CAN FD is already supported by SocketCAN on Linux, just enable the
fdcan pseudomodule and allow CAN FD frames.
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
RIOT implementation of CAN bus relies on SocketCAN model.
Since commit c398e56 (can: add optional DLC element to Classical CAN
frame structure), '__u8 can_dlc' attribute of struct can_frame is
considered as deprecated in SocketCAN and kept for legacy support.
Attribute '__u8 len' should be used instead.
union {
/* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
* was previously named can_dlc so we need to carry that
* name for legacy support
*/
__u8 len;
__u8 can_dlc; /* deprecated */
};
Moreover, CAN FD frame structure does not support legacy attribute
'can_dlc', making 'len' mandatory for incoming CAN FD support in RIOT.
struct canfd_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
__u8 len; /* frame payload length in byte */
__u8 flags; /* additional flags for CAN FD */
__u8 __res0; /* reserved / padding */
__u8 __res1; /* reserved / padding */
__u8 data[CANFD_MAX_DLEN]
__attribute__((aligned(8)));
};
Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>
Since https://github.com/RIOT-OS/RIOT/pull/20935 gpio_write()
uses a `bool` instead of an `int`. This does the same treatment for
`gpio_read()`.
This does indeed add an instruction to `gpio_read()` implementations.
However, users caring about an instruction more are better served with
`gpio_ll_read()` anyway. And `gpio_read() == 1` is often seen in
newcomer's code, which would now work as expected.
This changes a bunch of things that allows building with the musl C lib,
provided that `libucontext-dev` and `pkg-config` are installed.
Note that installing libucontext makes absolutely zero sense on C libs
that do natively provide this deprecated System V API, such as glibc.
Hence, it no sane glibc setup is expected to ever have libucontext
installed.
A main pain point was that argv and argc are expected to be passed to
init_fini handlers, but that is actually a glibc extension. This just
parses `/proc/self/cmdline` by hand to populate argv and argc during
startup, unless running on glibc.
This commit introduces a more robust GPIO mocking mechanism by utilizing
a 2-dimensional array. Each element of the array holds a gpio_mock_t
structure describing a pin's attributes such as value, mode, flank,
interruption callback, and callback argument.
This enhancement allows for the arbitrary simulation of GPIOs across
various microcontroller architectures using the current API, while
maintaining consistency through the use of the GPIO_PIN macro.
Additionally, it should be noted that only the maximum number of ports
and maximum number of pins can be altered according to the context.
The implemented API in gpio_mock.c remains rudimentary, providing no
validation but fulfilling the required functions. However, it remains
customizable as all its functions are marked as weak.
Signed-off-by: Gilles DOFFE <g.doffe@gmail.com>
If the gpio is initialized as an input or interruptable pin, the
gpio_mock driver returns -1 leading to failed initialization.
However that is not because nothing can change the GPIO state that it
has to be an error.
Return 0 in all cases.
Signed-off-by: Gilles DOFFE <g.doffe@gmail.com>
