Commit graph

8 commits

Author SHA1 Message Date
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
Henrik Brix Andersen c9da68290a modules: canopennode: use zephyr/dsp/types.h for float32_t/float64_t
Include the zephyr/dsp/types.h header for float32_t/float64_t type
definitions to avoid conflicts with other subsystems including this header.

Add compile-time asserts to ensure the typedefs meet the requirements of
the CANopenNode module.

Fixes: #63896

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2023-11-16 09:28:59 +01:00
Henrik Brix Andersen bc4b49c149 modules: canopennode: process rx buffers in priority order
The CANopenNode stack expects registered RX buffers to be processed and
matched in priority order. The priority corresponds to the index of each
each registered RX buffer with lower indexes having higher priority.

Depending on the CANopen COB-ID network configuration used, it may result
in overlapping CAN RX filters. In the case of overlaps, the priorities of
the registered RX buffers matter.

When receiving a CAN frame, process the RX buffers in priority order and
only dispatch the callback for the matching object with the highest
priority.

Fixes: #54364

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2023-02-23 07:54:02 -05:00
Carles Cufi 8e4d499fa0 treewide: Use CONFIG_*_ENDIAN instead of __BYTE_ORDER__
In order to avoid using multiple sources of truth for the platfom's
endianness, convert the in-tree code to use the (BIG|LITTLE)_ENDIAN
Kconfig variables exclusively, instead of the compiler's
__BYTE_ORDER__.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2022-10-28 19:23:46 +09:00
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-09-05 16:31:47 +02:00
Gerard Marull-Paretas 5f5a905784 modules: migrate includes to <zephyr/...>
In order to bring consistency in-tree, migrate all modules code to the
new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-06 19:57:47 +02:00
Henrik Brix Andersen 4216b9f622 modules: canopennode: rename header and Kconfig options
Rename the top-level header file from <canbus/canopen.h> to
<canopennode.h>.

Rename CANopenNode related Kconfig options from CONFIG_CANOPEN* to
CONFIG_CANOPENNODE*.

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2021-07-01 13:32:18 -04:00
Henrik Brix Andersen d679037643 modules: canopennode: move glue code to modules directory
Move the Zephyr-specific interface and support code for CANopenNode into
the modules directory. Consolidate the CMakeLists.txt files into one.

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2021-07-01 13:32:18 -04:00
Renamed from subsys/canbus/canopen/CO_driver_target.h (Browse further)