zephyr/modules/canopennode
Henrik Brix Andersen 3436c93387 drivers: can: remove run-time RTR filtering, add build-time RTR filter
A growing number of CAN controllers do not have support for individual RX
hardware filters based on the Remote Transmission Request (RTR) bit. This
leads to various work-arounds on the driver level mixing hardware and
software filtering.

As the use of RTR frames is discouraged by CAN in Automation (CiA) - and
not even supported by newer standards, e.g. CAN FD - this often leads to
unnecessary overhead, added complexity, and worst-case to non-portable
behavior between various CAN controller drivers.

Instead, move to a simpler approach where the ability to accept/reject RTR
frames is globally configured via Kconfig. By default, all incoming RTR
frames are rejected at the driver level, a setting which can be supported
in hardware by most in-tree CAN controllers drivers.

Legacy applications or protocol implementations, where RTR reception is
required, can now select CONFIG_CAN_ACCEPT_RTR to accept incoming RTR
frames matching added CAN filters. These applications or protocols will
need to distinguish between RTR and data frames in their respective CAN RX
frame handling routines.

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2024-01-21 11:00:31 +01:00
..
CMakeLists.txt
CO_driver.c drivers: can: remove run-time RTR filtering, add build-time RTR filter 2024-01-21 11:00:31 +01:00
CO_driver_target.h drivers: can: remove run-time RTR filtering, add build-time RTR filter 2024-01-21 11:00:31 +01:00
Kconfig crc: Make the build of crc function dependent on a Kconfig 2022-11-23 13:30:00 +01:00
canopen_leds.c
canopen_program.c modules: canopennode: Switch to FIXED_PARTITION_ macros 2022-09-06 09:56:37 +02:00
canopen_storage.c modules: canopennode: storage: fix size_t format specifier 2022-10-22 14:36:11 +09:00
canopen_sync.c
canopennode.h