Enable testing of all CiA recommended bitrates on the nucleo_h563zi,
where I can test, and the stm32h573i_dk, which is the testing platform
for the stm32h5 series.
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.com>
Reintroduce the overlays for native_sim/native/64 and
native_posix/native/64 to verify all bitrates on those platforms.
These were removed in fddbd79cf7.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The native_{posix,sim}_64 boards are not anymore twister
targets, native_{posix,sim}/native/64 are, and those
default to just use the overlays for the non variant
version.
These 2 overlays were not used by anything.
Remove them.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Enable testing of all CiA recommended bitrates on the following
simulated/emulated boards:
- native_sim
- native_sim_64
- native_posix
- native_posix_64
- qemu_x86
- qemu_x86_64
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
Twister now supports using YAML lists for all fields that were written
as space-separated lists. Used twister_to_list.py script. Some artifacts
on string length are due to how ruamel dumps content.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
Remove the CAN_HAS_CANFD Kconfig helper symbol in order to allow enabling
CAN-FD support in the API regardless of driver support.
Change default to CAN-FD support being disabled and have samples and tests
that require CAN-FD support turn it on. This aligns the default
configuration across CAN controller drivers regardless of their
capabilities.
The rationale behind this is that we are starting to see MCUs with multiple
CAN controllers, some CAN-FD compatible, some not (e.g. NXP i.MX RT1060 and
FPGAs). Automatically enabling CAN-FD support based on the presence of a
CAN-FD capable CAN controller leads to different application default
settings based on the CAN controller(s) in use.
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>
The .yaml file states that CAN is supported, but the basic sample
application samples/drivers/can/counter cannot be compiled without
additional configuration.
The loopback driver does not require any additional steps like the
linux SocketCAN driver, so it is safe to enable it by default and
get rid of the many overlay files in the tests.
ISO-TP tests and the counter sample are excluded via .yaml from
twister tests because of timing issues.
Signed-off-by: Martin Jäger <martin@libre.solar>
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>
- Filter out the CAN controller driver tests if no zephyr,canbus chosen
node is enabled in the devicetree.
- Rename the tests to follow the general test naming scheme.
- Remove the dedicated test selection for native_posix boards
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>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
