Rename the "bus_speed" and "bus_speed_data" fields of struct
can_driver_config to "bitrate" and "bitrate_data" to match the
corresponding devicetree properties and the terminology used in the rest of
the CAN subsystem API.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Deprecate the CAN controller bus-speed/bus-speed-data properties and rename
them to bitrate/bitrate-data to match the terminology used in other CAN
devicetree properties and the CAN subsystem API.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Namespaced the generated headers with `zephyr` to prevent
potential conflict with other headers.
Introduce a temporary Kconfig `LEGACY_GENERATED_INCLUDE_PATH`
that is enabled by default. This allows the developers to
continue the use of the old include paths for the time being
until it is deprecated and eventually removed. The Kconfig will
generate a build-time warning message, similar to the
`CONFIG_TIMER_RANDOM_GENERATOR`.
Updated the includes path of in-tree sources accordingly.
Most of the changes here are scripted, check the PR for more
info.
Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Set the default initial bitrates globally via Kconfig. The initial bitrates
can still be overridden using the "bus-speed" and "bus-speed-data"
devicetree properties.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Validate the CAN ID and CAN ID mask used in the can_filter struct before
passing it to the driver.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Since the minimum/maximum supported bitrates are now stored in the common
CAN controller driver configuration struct, retrieving these can no longer
fail.
Add new CAN controller API functions can_get_bitrate_min() and
can_get_bitrate_max() reflecting this and deprecate the existing
can_get_min_bitrate() and can_get_max_bitrate().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Bump the CAN controller API version from 1.0.0 to 1.1.0 to reflect bus
recovery API changes introduced for v3.7.0.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Deprecate CAN_MAX_STD_ID/CAN_MAX_EXT_ID macros in favor of
CAN_STD_ID_MASK/CAN_EXT_ID_MASK.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Use is_null_no_warn() for checking the init_fn against NULL in order to
avoid compiler warning when using CONFIG_COMPILER_SAVE_TEMPS=y.
Fixes: #70390
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add a utility macro for calculating the Transmitter Delay Compensation
(TDC) Offset using the sample point and CAN core clock prescaler specified
by a set of data phase timing parameters.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Based on information from doc/develop/api/overview.rst, add current
version for some groups representing APIs, following the following
table:
- Experimental: 0.1.0
- Unstable: 0.8.0
- Stable: 1.0.0
Also based on doc/develop/api/overview.rst, add 'since' tag to the
groups.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a new CAN controller API function can_get_min_bitrate() for getting the
minimum supported bitrate of a CAN controller/transceiver combination.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for specifying the minimum bitrate supported by a CAN
controller in CAN_DT_DRIVER_CONFIG_GET() and
CAN_DT_DRIVER_CONFIG_INST_GET().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The can_get_core_clock() API function returns the core clock rate of the
CAN controller, which provides the minimum time quantum (mtq). This clock
can be further divided by the CAN clock prescaler, providing the time
quantum (tq).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Extend support for automatic sample point location to also cover
can_calc_timing() and can_calc_timing_data().
Previously, automatic sample point location was only supported by
can_set_bitrate() and can_set_bitrate_data().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Deprecate the can_calc_prescaler() API function, as it allows for bitrate
errors. Bitrate errors between nodes on the same network leads to them
drifting apart after the start-of-frame (SOF) synchronization has taken
place, leading to bus errors.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Since all CAN controllers drivers seem to support automatic recovery (for
any future drivers for hardware without this hardware capability this can
easily be implemented in the driver), change the Zephyr CAN controller API
policy to:
- Always enable automatic bus recovery upon driver initialization,
regardless of Kconfig options. Since CAN controllers are initialized in
"stopped" state, no unwanted bus-off recovery will be started at this
point.
- Invert and rename the Kconfig CONFIG_CAN_AUTO_BUS_OFF_RECOVERY, which is
enabled by default, to CONFIG_CAN_MANUAL_RECOVERY_MODE, which is disabled
by default. Enabling CONFIG_CAN_MANUAL_RECOVERY_MODE=y enables support
for the can_recover() API function and a new manual recovery mode (see
next bullet). Keeping this guarded by Kconfig allows keeping the flash
footprint down for applications not using manual bus-off recovery.
- Introduce a new CAN controller operational mode
CAN_MODE_MANUAL_RECOVERY. Support for this is only enabled if
CONFIG_CAN_MANUAL_RECOVERY_MODE=y. Having this as a mode allows
applications to inquire whether the CAN controller supports manual
recovery mode via the can_get_capabilities() API function and either fail
or rely on automatic recovery - and it allows CAN controller drivers not
supporting manual recovery mode to fail early in can_set_mode() during
application startup instead of failing when can_recover() is called at a
later point in time.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add system call can_get_transceiver() for getting the CAN transceiver
associated with a CAN controller.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
Remove the CAN_FILTER_FDF flag for filtering on classic CAN/CAN FD frames
as it is not supported natively by any known CAN controller.
Applications can still filter on classic CAN/CAN FD frames in their receive
callback functions as needed.
Fixes: #64554
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>
The bit error counter is incremented when the CAN controller is unable to
transmit either a dominant or a recessive bit.
This new error counter should only be incremented directly if the CAN
controller is unable to distinquish between failure to transmit a dominant
versus failure to transmit a recessive bit. If the CAN controller supports
distinguishing between the two, either the `bit0` or `bit1` error counter
shall be incremented instead. Incrementing one of these will automatically
increment the bit error count as well.
Typically, a CAN controller driver will either use this new bit error
counter or the discrete bit0 and bit1 error counters depending on the
features supported by the hardware. Mixing the two on driver level should
not be required.
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 CAN timing calculation APIs to automatically calculate a default
(Re-)Synchronization Jump Width (SJW) value. The calculated value can be
overwritten by the caller if desired.
This allows automatically scaling the SJW according to the number of Time
Quanta (TQ) used for phase segment 2 instead of relying on a compile-time
fallback value defined in devicetree.
This reduces the can_set_timing()/can_set_timing_data() API functions to
simple setters (with validation).
Fixes: #63033
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rework the can_dlc_to_bytes table lookup code in a way that allow the
compiler to guess the resulting output and somehow fix the build
warning:
zephyr/drivers/can/can_nxp_s32_canxl.c:757:9: warning:
'__builtin___memcpy_chk' forming offset [16, 71] is out of the bounds
[0, 16] of object 'frame' with type 'struct can_frame' [-Warray-bounds]
757 | memcpy(frame->data, msg_data.data, can_dlc_to_bytes(frame->dlc));
where the compiler detects that frame->data is 8 bytes long but
can_dlc_to_bytes could return more than that.
Can be reproduced with:
west build -p -b s32z270dc2_rtu1_r52 \
-T samples/net/sockets/can/sample.net.sockets.can.one_socket
Suggested-by: Martin Jäger <martin@libre.solar>
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Check the requested CAN timing parameters against the min/max values
supported by the driver and return an error if they are out of range.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add definition for the CAN-FD Error State Indicator (ESI) flag. The
presence of this flag indicates that the transmitting CAN-FD node is in
error-passive state.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the can_utils_filter_match() utility function to
can_frame_matches_filter(), move it to the public
include/zephyr/drivers/can.h header file, and add a missing mismatch for
standard (11-bit) ID frames passing extended (29-bit) filters.
This allows using the utility function in out-of-tree CAN drivers.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The RX overrun counter is incremented when the CAN controller receives a
CAN frame matching an installed filter but lacks the capacity to store it
(either due to an already full RX mailbox or a full RX FIFO).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support FD frame filter to configure type frame for
each Rx msg to receive corresponding frames (classic, FD frames).
The Bosch M_CAN driver does not support FD frame filter,
so inmplement driver to handle it in software.
Signed-off-by: Cong Nguyen Huu <cong.nguyenhuu@nxp.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>
The can_set_timing_data() API function is optional and is not supported by
all CAN controller drivers.
On a board with only either classic CAN or CAN-FD capable controllers the
current behavior is fine, but on boards with a mix of classic CAN and
CAN-FD capable controllers/drivers, calling can_set_timing_data() on a
classic CAN controller will lead to a NULL pointer dereference.
To ensure a proper behavior when calling can_set_timing_data() on classic
CAN controller drivers, change the API wrapper function to return -ENOSYS
if the CAN driver does not implement CAN-FD support.
Note that the data phase timing calculation functions are fine as-is, as
the timing calculations will fail due to minimum/maximum data phase timing
parameters being all zeros for drivers only supporting classic CAN.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Some headers made use of types defined in sys_clock.h (e.g. k_timeout_t)
without including it.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
With the incoming removal of kernel.h/types.h from init.h, lots of files
start to show compile errors because they relied on indirect
definitions, including errno.h.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
