Add CAN driver support for Renesas RZ/G3S
Signed-off-by: Hieu Nguyen <hieu.nguyen.ym@bp.renesas.com>
Signed-off-by: Nhut Nguyen <nhut.nguyen.kc@renesas.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>
Optionally bypass the shell when printing received CAN frames in order not
to break up the line containing the frame. This allows for parsing the
printed CAN frames using Twisters pytest and console harnesses with the
cost of the shell ignoring input while the frame is being printed.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.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>
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>
Adds CAN drivers for XMC4xxx SoCs.
XMC4xxx has multiple CAN nodes. The nodes share a common clock and
a message object pool.
The CAN nodes do not have a loopback mode. Instead there is an
internal bus which can be used to exchange messages between
nodes on the SoC. For this reason tests/samples which rely on the
loopback feature have been disabled.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.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>
Rename the native Linux SocketCAN driver to reflect that it can can now be
used in both native_posix and native_sim (with or without an embedded
C-library).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Do not enable subsystem/driver shell modules by default and stop abusing
CONFIG_SHELL_MINIMAL, which is internal to the shell subsystem, to decide
when to enable a driver shell.
The list of shell modules has grown considerably through the
years. Enabling CONFIG_SHELL for doing e.g. an interactive debug session
leads to a large number of shell modules also being enabled unless
explicitly disabled, which again leads to non-negligible increases in
RAM/ROM usage.
This commit attempts to establish a policy of subsystem/driver shell
modules being disabled by default, requiring the user/application to
explicitly enable only those needed.
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>
This continue PR #31270. The updated changes are:
- Updated to work with latest zephyr
- Inplace reads/writes of registers
- Batch read of RX messages when multiple messages can be read
- FIFO abstraction of RX/TEF queues
- Handle ivmif errors
- Use READ_CRC for register reads
- Use bitmasks instead of bitfield members
- Rename mcp25xxfd to mcp251xfd
- General cleanups
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Add driver for the TI TCAN4x5x series of CAN controllers. These CAN
controllers are based on the Bosch M_CAN IP and interfaced via an SPI bus.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Increase the default CAN controller driver initialization priority from
KERNEL_INIT_PRIORITY_DEVICE (50) to 80 to allow CAN controllers on SPI
busses have their bus initialized prior to initializing the CAN controller
driver.
The only in-bound dependency on CAN controller drivers - apart from
application level code - is the drivers/net/canbus.c driver, which already
defaults to an initialization level of 81.
Fixes: #55745
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Driver was based on can_sam. SAMC21 has only 1 interrupt for one
can "output", so can interrupt has to executes two lines of
interrupts.
CAN is configured to use OSC48M clock via GLCK7. GLCK7 is set
by divider configured from dts.
Signed-off-by: Kamil Serwus <kserwus@gmail.com>
This patch introduces support for NXP S32 CANEXCEL (CANXL) peripheral.
CAN protocol supporting:
- CAN classic
- CAN FD
Remote transmission request is not supported as this feature is not
available on NXP S32 CANXL HAL.
Signed-off-by: Cong Nguyen Huu <cong.nguyenhuu@nxp.com>
Unify the drivers/*/Kconfig menuconfig title strings to the format
"<class> [(acronym)] [bus] drivers".
Including both the full name of the driver class and an acronym makes
menuconfig more user friendly as some of the acronyms are less well-known
than others. It also improves Kconfig search, both via menuconfig and via
the generated Kconfig documentation.
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>
Remove the CAN_HAS_RX_TIMESTAMP Kconfig helper symbol in order to allow
enabling CAN RX timestamps in the API regardless of driver support.
This simplifies application prj.conf settings across board supporting/not
supporting RX timestamps considerably.
CAN drivers not supporting RX timestamps already initialize the timestamp
to 0 for received frames.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for configuring CAN emulation support in QEMU. For now, the
only supported CAN controller is the single-channel Kvaser PCIcan PCI card.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
This driver provides an interface to SocketCAN interfaces of the Linux
system running a Zephyr application with the native_posix board. These
interfaces may be virtual or actual CAN buses.
Signed-off-by: Martin Jäger <martin@libre.solar>
Remove the Kconfig option for configuring the maximum value of the CAN-FD
Data Length Code in order to ensure standard compliance.
Allowing users to configure the max DLC allows the user to save a number of
bytes per CAN frame in RAM, but it also renders the Zephyr CAN-FD
implementation non-compliant with the CAN-FD standard.
There are no guarantees that a Zephyr CAN-FD node will not receive a CAN
frame with a DLC higher than the Kconfig limit, which opens up for all
sorts of bugs when trying to handle received CAN-FD frames.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add ESP32 TWAI CAN controller driver. The TWAI is register-compatible with
the NXP SJA1000 CAN controller.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Move the CAN bus network driver from drivers/can to drivers/net as it
implements a network driver, not a CAN controller driver.
Use a separate Kconfig for enabling the CAN bus network driver instead of
piggybacking on the SocketCAN Kconfig. This allows for other
(e.g. out-of-tree) SocketCAN transports.
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>
According to Kconfig guidelines, boolean prompts must not start with
"Enable...". The following command has been used to automate the changes
in this patch:
sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig*
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add CAN controller device statistics support.
Initially the following per-device statistics are supported:
- Dominant bit transmission errors
- Recessive bit transmission errors
- Bit stuffing errors
- CRC errors
- Format errors
- Acknowledge errors
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
* New m_can driver variant for STM32H7, as it uses the complete m_can
register set.
* Fix definitions for CAN_MCAN_RXF0S_F0FL, CAN_MCAN_TXEFC_EFSA_POS.
Signed-off-by: Jeremy Wood <jeremy@bcdevices.com>
Deprecate the can_attach_workq() API call.
This API is limited in its functionality (it does not work with
userspace, it uses one common buffer size for all work queue instances).
Similar functionality can easily be implemented using the
can_attach_msgq() API along with the generic triggered work API
(e.g. using k_work_poll_submit()).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Convert the CAN shell from using can_attach_workq() to using
can_attach_msgq() and triggered work via k_work_poll_submit().
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
Instead of explicity ORing together the compatible drivers,
CAN_RX_TIMESTAMP now depends on CAN_HAS_RX_TIMESTAMP
which is selected by the drivers primary Kconfig option. In addition,
stm32fd does not need to select this option since it selected by
the underlying M_CAN driver.
Signed-off-by: Abram Early <abram.early@gmail.com>
This driver is for classic CAN, it makes use of CAN interface
in FIFO mode.
This driver support Standard ID as well as Extended ID.
Tested on H3ULCB, Ebisu platform, with external adapter and
in loopback mode.
Signed-off-by: Julien Massot <julien.massot@iot.bzh>
Implementation of the Bosch M_CAN IP driver.
This driver is just the base for a specific SoC implementation.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
The previous API can't change the sampling-point and only allowed
bitrates that fit the time segments.
The new API allows for shifting the sampling-point and adjusts the
number of time quantum in a bit to all more possible bitrates.
The functions to calculate the timings are moved to the can_common file.
They can be used for all drivers.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
