Unify spelling of CAN Flexible Data-rate abbreviation to "CAN FD" instead
of "CAN-FD". The former aligns with the CAN in Automation (CiA)
recommendation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add a simple test to validate that the CAN statistics accessor functions
can be called from user mode threads.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Update the CAN controller drivers to solely use the sjw and sjw-data
devicetree properties for setting the initial timing when devicetree timing
parameters are specified in Time Quanta (TQ).
Any timing set via the CAN timing APIs will contain either user-provided or
automatically calculated SJW values. This includes any timing parameters
calculated from bus-speed and bus-speed-data devicetree properties.
Update the CAN controller driver tests accordingly and remove the
CAN_SJW_NO_CHANGE definition as it has lost its meaning.
Fixes: #63033
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Change the test_set_timing_data_while_started test to actually attempt to
set the data phase timing parameters instead of attempting to set the
nominal/arbitration timing parameters.
Update test descriptions to explicitly mention data phase timing.
Fixes: #59046
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Test that filters are preserved when changing between CAN-FD mode and
classic CAN mode and vice versa.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Adjust the CAN IDs used for testing in order for them to match the various
can_*_filter_2 as documented in common.h.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the test definitions, frames, and filters to common.h/common.c and
reuse them between the classic CAN and CAN-FD API tests.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Fold the CAN-FD specific tests into the main CAN API tests and stop
treating the CAN-FD API functionality as an add-on to CAN API.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The can_frame and can_filter structs support a number of different flags
(standard/extended CAN ID type, Remote Transmission Request, CAN-FD format,
Bit Rate Switch, ...). Each of these flags is represented as a discrete bit
in the given structure.
This design pattern requires every user of these structs to initialize all
of these flags to either 0 or 1, which does not scale well for future flag
additions.
Some of these flags have associated enumerations to be used for assignment,
some do not. CAN drivers and protocols tend to rely on the logical value of
the flag instead of using the enumeration, leading to a very fragile
API. The enumerations are used inconsistently between the can_frame and
can_filter structures, which further complicates the API.
Instead, convert these flags to bitfields with separate flag definitions
for the can_frame and can_filter structures. This API allows for future
extensions without having to revisit existing users of the two
structures. Furthermore, this allows driver to easily check for unsupported
flags in the respective API calls.
As this change leads to the "id_mask" field of the can_filter to be the
only mask present in that structure, rename it to "mask" for simplicity.
Fixes: #50776
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Skip the Remote Transmission Request (RTR) frame tests if the CAN
controller driver does not support RTR filters.
Fixes: #50218
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Up until now, the Zephyr CAN controller drivers set a default bitrate (or
timing) specified via devicetree and start the CAN controller in their
respective driver initialization functions.
This is fine for CAN nodes using only one fixed bitrate, but if the bitrate
is set by the user (e.g. via a DIP-switch or other HMI which is very
common), the CAN driver will still initialise with the default
bitrate/timing at boot and use this until the application has determined
the requested bitrate/timing and set it using
can_set_bitrate()/can_set_timing().
During this period, the CAN node will potentially destroy valid CAN frames
on the CAN bus (which is using the soon-to-be-set-by-the-application
bitrate) by sending error frames. This causes interruptions to the ongoing
CAN bus traffic when a Zephyr-based CAN node connected to the bus is
(re-)booted.
Instead, require all configuration (setting bitrate, timing, or mode) to
take place when the CAN controller is stopped. This maps nicely to entering
"reset mode" (called "configuration mode" or "freeze mode" for some CAN
controller implementations) when stopping and exiting this mode when
starting the CAN controller.
Fixes: #45304
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Many device pointers are initialized at compile and never changed. This
means that the device pointer can be constified (immutable).
Automated using:
```
perl -i -pe 's/const struct device \*(?!const)(.*)= DEVICE/const struct
device *const $1= DEVICE/g' **/*.c
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove the "z" prefix from the public CAN controller API types as this
makes them appear as internal APIs.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add a bunch of missing "zephyr/" prefixes to #include statements in
various test and test framework files.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Convert the can_mode enum to a bit field to prepare for future extensions
(CAN-FD mode, transmitter delay compensation, one-shot mode, 3-samples
mode, ...).
Rename the existing modes:
- CAN_NORMAL_MODE -> CAN_MODE_NORMAL
- CAN_SILENT_MODE -> CAN_MODE_LISTENONLY
- CAN_LOOPBACK_MODE -> CAN_MODE_LOOPBACK
These mode names align with the Linux naming for CAN control modes.
The old CAN_SILENT_LOOPBACK_MODE can be set with the bitmask
(CAN_MODE_LISTENONLY | CAN_MODE_LOOPBACK).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
In order to bring consistency in-tree, migrate all tests to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add simple test of the can_set_state_change_callback() API. It is not
possible to trigger a change of state, but at least test the API call
with and without a callback function.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Include a pointer to the CAN controller device for the CAN
transmit, receive, and state change callback functions.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename a few CAN API functions for clarity and consistency with other
Zephyr RTOS APIs.
CAN_DEFINE_MSGQ() becomes CAN_MSGQ_DEFINE() to match K_MSGQ_DEFINE().
can_attach_isr() becomes can_add_rx_filter() since a filter callback
function is not an interrupt service routine (although it is called in
isr context). The word "attach" is replaced with "add" since filters are
added, not attached. This matches the terminology used is other Zephyr
APIs better.
can_detach() becomes can_remove_rx_filter() to pair with
can_add_rx_filter().
can_attach_msgq() becomes can_add_rx_filter_msgq() and documentation is
updated to mention its relationship with can_add_rx_filter().
can_register_state_change_isr() becomes can_set_state_change_callback()
since a state change callback function is not an interrupt service
routine (although it is called in isr context). The word "register" is
replaced with "set" since only one state change callback can be in
place.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Convert the CAN loopback driver from being configured via Kconfig to
multi-instance configured via devicetree.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Change the can_tx_callback_t function signature to use an "int" (not an
uint32_t) for representing transmission errors.
The "error" callback function parameter is functionally equivalent to
the return value from can_send() and thus needs to use the same data
type and needs to be able to hold negative errno values.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove the tests for can_attach_workq() and convert the
test_send_receive_buffer() test case to using a message queue.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Deprecate the use of CAN-specific error return values and replace them
with standard errno values.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove the DT_CHOSEN_ZEPHYR_CANBUS_LABEL macro and replace it with
DEVICE_DT_GET(DT_CHOSEN(zephyr_canbus)) were possible.
Where both devicetree CAN controllers and Kconfig specified CAN loopback
controllers are supported, the macro is replaced with
DT_LABEL(DT_CHOSEN(zephyr_canbus)) for now.
This is the first pass for removing the requirement for devicetree
labels for CAN controllers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
