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>
To avoid type conflicts between the `pthread_rwlockattr_t` definition in RIOT's `pthread` implementation and newlibc's `sys/_pthreadtypes.h`, the macro `_POSIX_READER_WRITER_LOCKS` must be undefined.
The cleanup reduces the number of linker scripts used for the ESP32x ROMs and thus the symbols used from the ESP32x ROMs. It works with both gcc 12.2 and gcc 14.2. The latter gcc version is a prerequisite for ESP-IDF v5.2 and higher and thus a prerequisite for starting the work on the RIOT-OS port for the latest version of ESP-IDF.
This changes the API of xfa from
XFA(array_name, prio) type element_name = INITIALIZER;
to
XFA(type, array_name, prio) element_name = INITIALIZER;
this allows forcing natural alignment of the type, fixing failing tests
on `native64`.
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.
The assumption that every MCU has this feature turned out wrong. Hence,
add a feature to allow testing for support of edge triggered IRQs on
both flanks.
The API was based on the assumption that GPIO ports are mapped in memory
sanely, so that a `GPIO_PORT(num)` macro would work allow for constant
folding when `num` is known and still be efficient when it is not.
Some MCUs, however, will need a look up tables to efficiently translate
GPIO port numbers to the port's base address. This will prevent the use
of such a `GPIO_PORT(num)` macro in constant initializers.
As a result, we rather provide `GPIO_PORT_0`, `GPIO_PORT_1`, etc. macros
for each GPIO port present (regardless of MCU naming scheme), as well as
`GPIO_PORT_A`, `GPIO_PORT_B`, etc. macros if (and only if) the MCU port
naming scheme uses letters rather than numbers.
These can be defined as macros to the peripheral base address even when
those are randomly mapped into the address space. In addition, a C
function `gpio_port()` replaces the role of the `GPIO_PORT()` and
`gpio_port_num()` the `GPIO_PORT_NUM()` macro. Those functions will
still be implemented as efficient as possible and will allow constant
folding where it was formerly possible. Hence, there is no downside for
MCUs with sane peripheral memory mapping, but it is highly beneficial
for the crazy ones.
There are also two benefits for the non-crazy MCUs:
1. We can now test for valid port numbers with `#ifdef GPIO_PORT_<NUM>`
- This directly benefits the test in `tests/periph/gpio_ll`, which
can now provide a valid GPIO port for each and every board
- Writing to invalid memory mapped I/O addresses was treated as
triggering undefined behavior by the compiler and used as a
optimization opportunity
2. We can now detect at compile time if the naming scheme of the MCU
uses letters or numbers, and produce more user friendly output.
- This is directly applied in the test app
- `gpio_ll_toggle()` now is race-free
- avoid using a look up table but branch to the two different registers
in the `gpio_ll*()` functions
- in most cases the GPIO port is a compile time constant and the
dead branch is eliminated by the optimizer, making this vastly
more efficient
- some MCUs do only have a single port, in which case
`GPIO_PORT_NUM(port)` is known to return `0` even if `port` is
not known, resulting in one of the branch being eliminated as
dead branch no matter what
- in case it really is unknown at compile time which port to work
on, the branch can still be implemented efficiently by the
compiler e.g. using a conditional move; likely more efficient
than fetching a value from the look up table.
This adds the features
- periph_gpio_ll_input_pull_down:
To indicate support for input mode with internal pull down
- periph_gpio_ll_input_pull_keep:
To indicate support for input mode with internal resistor
pulling towards current level
- periph_gpio_ll_input_pull_up:
To indicate support for input mode with internal pull up
- periph_gpio_ll_disconnect:
To indicate a GPIO can be disconnected
- periph_gpio_ll_open_drain:
To indicate support for open drain mode
- periph_gpio_ll_open_drain_pull_up:
To indicate support for open drain mode with internal pull up
- periph_gpio_ll_open_source:
To indicate support for open source mode
- periph_gpio_ll_open_source_pull_down:
To indicate support for open source mode with internal pull down
This commit optimizes the `gpio_conf_t` type in the following
regards:
- The "base" `gpio_conf_t` is stripped from members that only some
platforms support, e.g. drive strength, slew rate, and disabling of
the Schmitt Trigger are no longer universally available but
platform-specific extensions
- The `gpio_conf_t` is now crammed into a bit-field that is 8 bit or
16 bit wide. This allows for storing lots of them e.g. in
`driver_foo_params_t` or `uart_conf_t` etc.
- A `union` of the `struct` with bit-field members and a `bits` is used
to allow accessing all bits in a simple C statement and to ensure
alignment for efficient handling of the type
Co-authored-by: Gunar Schorcht <gunar@schorcht.net>
