Some CAN controllers may be unable to meet all bitrates due to timing
restrictions, but assert that at least one of the tested bitrates was
supported.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add tests for all CAN bitrates recommended by CAN in Automation (CiA). The
newly added bitrate tests are guarded by new, local Kconfig option
(CONFIG_TEST_ALL_BITRATES) to avoid breaking existing board tests.
Some boards may need adjustments to their CAN core clock in order to pass
the newly added tests. Once a board is confirmed to meet these additional
checks, this Kconfig can be enabled for that board to avoid future
regressions.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove tests for additional sample points as this does not provide any real
value.
The purpose of this test suite is to see if the selected CAN clock allows
meeting the standard bitrates and sample points used by Zephyr. Any
tweaking needed for a specific board or system design is left up to the
user and not something that can be covered by testing a few additional
sample point locations.
Change a few comments and remove an unneeded conditional while here.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the tests for using invalid sample points from the CAN timing tests to
the CAN API tests as these are validating basic API behavior.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the tests for setting a too high bitrate from the CAN timing tests to
the CAN API tests as these are validating basic API behavior.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the test for setting the minimum/maximum supported timing parameters
from the CAN timing tests to the CAN API tests as these are validating
basic API behavior.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Enable testing of all bitrates for all drivers and report which bitrates
are not supported by the CAN controller under test.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
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>
Use the recommended sample point of 75.0% for the data phase bitrate test @
1Mbit/s. This matches the default sample point calculated in
can_common.c:sample_point_for_bitrate().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Remove test for attempting to set an arbitration bitrate of
8000001 bit/s. This test belongs in the data phase timing test, where
it already present as well.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Use the CAN controller driver capabilities to determine if the CAN-FD
timing tests should be skipped or not. There is no need for special
handling of CONFIG_CAN_FD_MODE.
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>
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>
Exclude the 20kbit/s CAN timing test from running on the Espressif ESP32
TWAI driver. The TWAI does not support bitrates below 50kbit/s due to the
combination of CAN clock and prescaler range.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Rename the CAN data phase API functions to timing_data_* for consistency:
- can_get_timing_min_data() -> can_get_timing_data_min()
- can_get_timing_max_data() -> can_get_timing_data_max()
- .timing_min_data -> timing_data_min
- .timing_max_data -> timing_data_max
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>
Print the CAN core clock frequency along with the device name to aid in
debugging CAN timing test case errors.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Tighten the sample point test acceptance criteria from +/- 10.0% to +/-
5.0%. This is in line with the CAN sample point criteria used by the
Linux kernel.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Do not overwrite the sample point error value as it is printed at the
very end of the test.
Fixes: 578454b78d
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Adjust the sample point locations for the higher bitrates to match those
used in the Linux kernel. These sample points are much more likely to be
met for a wider set of CAN controllers and their timing parameter
boundaries.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Extend the CAN driver timing tests to cover data phase timing on CAN-FD
capable CAN controllers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Extend the CAN driver timing calculation test verification to cover the
sjw and prescaler values.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Convert the CAN timing test to the new ztest framework. Restructure the
tests a bit to improve code readability and add doxygen documentation.
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>
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>
Rename the Zephyr chosen property for specifying the default CAN bus
controller from "zephyr,can-primary" to "zephyr,canbus".
The "zephyr,can-primary" property name was selected in antipation of
adding support for redundant CAN networks, which we have yet to
add. Meanwhile, the "primary" term causes confusion for non-redundant
CAN bus configurations (and the "can" term doesn't match the name of the
Zephyr CAN bus subsystem).
The CAN in Automation (CiA) 302-6, which deals with CANopen network
redundancy, uses the terms "default interface" and "redundant
interface". If/when we add support for redundant CAN networks, the
"zephyr,canbus" chosen property can be supplemented with a
"zephyr,canbus-redundant" chosen property.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
If the prescaler is zero in the test, a div by zero would happen.
Add an assert to check for zero prescaler.
Fix CID 216790
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
Added tests for the timing algorithm.
The tests calculate timings for some bitrates with sample-points
and verify the results.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
