The timing_max parameters defined in the stm32 bxcan driver don't match the
register description in the reference manuals.
- sjw does have only 2 bits representing 1 to 4 tq.
- phase_seg1 and phase_seg2 max is one tq higher.
I have checked the following reference manuals and all match:
- RM0090: STM32F405, F415, F407, F417, F427, F437 AND F429
- RM0008: STM32F101, F102, F103, F105, F107 advanced arm-based mcus
- RM0351, RM0394: all STM32L4
- RM0091: all STM32F0 with CAN support
Signed-off-by: Thomas Stranger <thomas.stranger@outlook.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>
Change automated searching for files using "IRQ_CONNECT()" API not
including <zephyr/irq.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Given the recent change to the CAN controller can_send() API wrapper,
assume that a callback is always provided at the driver level.
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>
Change the error code for can_send() when the CAN controller is in bus off
state from -ENETDOWN to -ENETUNREACH.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the can_state enumerations to contain the word STATE to make their
meaning more clear:
- CAN_ERROR_ACTIVE => CAN_STATE_ERROR_ACTIVE
- CAN_ERROR_WARNING => CAN_STATE_ERROR_WARNING
- CAN_ERROR_PASSIVE => CAN_STATE_ERROR_PASSIVE
- CAN_BUS_OFF => CAN_STATE_BUS_OFF
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
The previous driver implementation aimed to maximize the amount of
filters, which resulted in a fairly complex implementation.
Background: The bxCAN assigns a number to the filters in the order they
appear in the filter banks. This number is used to match messages in
the FIFO with their filter. If the scale or mode of a filter bank is
changed, all following filter numbers get an offset and the assigned
callbacks have to be shifted accordingly.
The required additional space for the shifting operations resulted in
non-deterministic behaviour and the maximum number of filters could not
be determined at compile-time, which made several tests like
tests/drivers/can/api fail.
This implementation uses a more simple but reliable approach for
filtering and and reserves fixed space for extended and standard ID
filters in the available banks (configurable via Kconfig).
The list mode is not used, which may reduce the total number of usable
filters depending on the application.
The maximum amount of filters is 14 if all filters use ext. IDs,
28 if all use std IDs and something in between if mixed IDs are used.
Also see issue #47986 for more detailed background information.
Signed-off-by: Martin Jäger <martin@libre.solar>
Namespace local functions, enums, structs and defines with stm32/STM32
to distinguish them from global CAN API.
Also rename some internal conversion functions to make their meaning
more clear and delete unused defines.
Signed-off-by: Martin Jäger <martin@libre.solar>
Add API function for getting the supported capabilities of a CAN
controller. This allows for writing portable CAN applications.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Switch from using a driver-specific, compile-time devicetree one-shot
property to supporting the newly added CAN_MODE_ONE_SHOT flag for
enabling/disabling one-shot mode at run-time.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
CAN1 and CAN2 share the memory for the filter banks.
This commit adds an offset for filters installed for CAN2, allowing to
use both CAN instances simultaneously.
The hardware allows to freely split the avalable 28 filters between
CAN1 and CAN2. In order to simplify the driver implementation, it only
supports an equal split of 14 filters per instance. This is the same
amount of filters as available in MCUs with only a single CAN.
Signed-off-by: Martin Jäger <martin@libre.solar>
Remove two functions which were only called from one place and did
not improve readibility of the code.
Signed-off-by: Martin Jäger <martin@libre.solar>
This commit unifies the driver initialization for can1 and can2
instances so that a single macro can be used.
Enabling the master clock for can2 as introduced in 8ab81b02 had to
be moved to devicetree in order to have the same CAN_STM32_CONFIG_INST
macro for all instances.
Signed-off-by: Martin Jäger <martin@libre.solar>
For devices with more than one CAN peripherals, CAN1 is the master and
its clock has to be enabled also if only CAN2 is used.
Signed-off-by: Martin Jäger <martin@libre.solar>
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 drivers 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>
Remove support for the optional API function can_get_max_filters() from
the STM32 bxCAN driver for now.
The function returns the Kconfig value for the maximum number of filters
but the true number of supported filters may be different due to the
filter nature of the STM32 bxCAN driver implementation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Move the code for socket instanciation from each driver
to a generic driver, that makes an instance of a socketCAN
net device for the chosen node.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
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>
Only call the state change callback if the state has changed. Reuse the
existing function for retrieving the CAN controller state instead of
having the same code twice.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The CAN_BUS_UNKNOWN CAN controller state is only used to indicate that
the current CAN controller state could not be read.
Remove it and change the signature of the can_get_state() API function
to return an integer indicating success or failure.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Stop using redundant DEV_DATA/DEV_CFG macros and use dev->data and
dev->config instead.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add support for disabling automatic retransmission of CAN frames
(similar to CAN "one-shot" mode in the Linux kernel).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add optional user data argument to can_set_state_change_callback() to
comply with Zephyr API design guidelines.
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>
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>
The PINCTRL_DT_(INST_)DEFINE macros already defined the trailing ;,
making its usage inconsistent with other macros such as
DEVICE_DT_DEFINE.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
Catch up on the CAN driver API argument naming changes:
- Unify naming of callback function pointers as "callback".
- Unify naming of user-specified callback function arguments as
"user_data".
- Instances and pointers to struct zcan_frame are named "frame",
not "msg", to avoid confusion with the CAN message queue support.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Trivial fix of compilation error "invalid operands to binary "
when CONFIG_CAN_AUTO_BUS_OFF_RECOVERY = n
Fixes#40290
Signed-off-by: Lucas Dietrich <ld.adecy@gmail.com>
The maximum number of concurrent filters depends on the hardware and
the driver implementation. This API allows the application to obtain
the maximum number of available filters.
Signed-off-by: Martin Jäger <martin@libre.solar>
Refactors all of the CAN drivers to use a shared driver class
initialization priority configuration, CONFIG_CAN_INIT_PRIORITY, to
allow configuring CAN drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The exception
is the mcp2515 driver which has a dependency on a SPI driver and must
therefore initialize later than the default device priority.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
