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>
The CDB module is a mandatory part of provisioning features in BTM, and
can not be regarded as experimental anymore.
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
This adds some skeleton files to enable using LSM6DSO on I3C bus
while still acting like a I2C device. The new files here are
simply to provide a way to have overlay for each board that
would not conflict with the pure I2C one. Also this is set to
build only because it require external hardware that is not
necessary on the board being tested.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds some skeleton files to enable using LPS22HH on I3C bus.
This still uses the C source file for I2C. The new files here
are simply to provide a way to have overlay for each board that
would not conflict with the I2C one. Also this is set to build
only because it may require external hardware that is not
necessary on the board being tested.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Updated the document with the correct west build command,
and done some restructuring as well.
Signed-off-by: Rajkumar Kanagaraj <rajkumar.kanagaraj@linaro.org>
Add the flash channel support by implementing the controller attached
flash sharing APIs, including flash_read, flash_write, and flash_erase.
For flash_read, the max data payload the module can support is 64 bytes
in one transaction.
For flash_write, the max data payload the module can support is 16
bytes in one transaction.
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
The current stm32l562_dk_ns has no flash partitions defined. This add
flash partitions following partition sizes that are compatible with
the TF-M platform defined at flash_layout.h and removes the redundant
overlays board files.
Signed-off-by: Gerson Fernando Budke <gerson.budke@ossystems.com.br>
Adds the dma transfer for the octoSPI on NOR octo Flash
of the stm32h7b3i and stm32h735g disco kits.
The channel for the MDMA is 0-15.
The MDMA request is 0x16 for the OCTOSPI1 fifo threshold
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Adds the dma transfer for the octoSPI on NOR octo Flash
of the stm32l562e_dk disco kit.
The channel for the DMAMUX is 0-15 (0-7 for DMA1, 8-15 for DMA2)
The DMAMUX request is 41 for the OCTOSPI.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
After add zephyr,flash-controller property, most gd32 boards support
flash_shell sample.
gd32vf103c_starter and gd32vf103v_eval only have 32KB SRAM, so we
should reduce CONFIG_HEAP_MEM_POOL_SIZE to 8KB.
gd32f350r_eval only have 16KB driver, exclude from flash_shell sample.
Signed-off-by: HaiLong Yang <hailong.yang@brainco.cn>
The FRDM-K64F board has a SD/MMC slot. This patch modifies the DTS
files so that this feature works out of the box. This includes
configuring the SPI peripheral connected to the slot on the board.
This change follows the SD/MMC support for other boards, e.g.
Olimexino-STM32. It was tested on a FRDM-K64F board with the
fat_fs sample.
Signed-off-by: Marek Materzok <tilk@tilk.eu>
Use dts overlay to declare the pwm-led only when needed.
This is only used for demo purpose of PWM0 on RCAR gen3
boards (H3ULCB only at the moment).
Signed-off-by: Pierre Marzin <pierre.marzin@iot.bzh>
Even though we have unit tests that cover the PM policy latency APIs, it
may not be obvious on how to use it in practice. This patch adds a new
sample where both the application and a device driver impose latency
requirements. The sample illustrates how latency requirements are
aggregated and are taken into account when choosing the CPU power state.
The test has been designed to run on native_posix, since it only serves
for demonstration purposes.
Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
Increase the Controller supported Advertising Data Length
Maximum so that Advertising Data set by Broadcast Audio
Source sample is accepted by the controller.
Also, tune down the supported ISO Tx PDU size to suffice the
Broadcast Audio Source usecase.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
In a Controller Area Network a babbling node is a node continuously (and
usually erroneously) transmitting CAN frames with identical - often high -
priority. This constant babbling blocks CAN bus access for any CAN frame
with lower priority as these frames will loose the bus arbitration.
Being able to simulate a babbling CAN node is useful when examining the
behavior of other nodes on the same CAN bus when they constantly loose bus
arbitration.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
The commit switches flash area access from FLASH_AREA_ macros
to FIXED_PARTITION_ macros and to usage of DTS node labels,
to identify partitions, instead of label property.
Signed-off-by: Dominik Ermel <dominik.ermel@nordicsemi.no>
If a L2 link has been established, then the DHCP is taking too long as
it has to go through its capped exponential backoff timers to trigger
discover (The DHCP starts immediately during init, this is itself wrong,
it should start on a link UP notification) that delays the DHCP for
few seconds to a minute.
And if we do stop and start DHCP then also it goes through the initial
delays (though configurable), which is also not ideal.
Add support for restarting DHCP without any delay, i.e., release and
send discover immediately.
This is also useful in case L2 switches to a different subnet, in this
case Zephyr doesn't restart DHCP automatically, this API can be used by
L2 apps/drivers to restart DHCP to get new subnet IP.
Signed-off-by: Krishna T <krishna.t@nordicsemi.no>
Updated the iso_receive sample to configure and synchronize
upto 2 BISes in the created BIG sync.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
`samples/net/wifi` replaces custom esp32 wifi sample
code. Then it can be removed from main repository.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
Moved all MBEDTLS dependencies from prj.conf
to Kconfig as WiFi depends on it.
Update esp32 wifi driver to enable `samples/net/wifi`
to work. Commands as such as `wifi connect` and `wifi scan` are now
available.
Signed-off-by: Sylvio Alves <sylvio.alves@espressif.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This PR adds a `*_cli_*` infix to the Config Client API to match
the changes in Health Client. The old API is marked as deprecated.
Signed-off-by: Michal Narajowski <michal.narajowski@codecoup.pl>
This header is also needed for struct can_filter, so it should not
only be included if one wants to set the device into loopback mode.
Signed-off-by: Martin Jäger <martin@libre.solar>
https://github.com/zephyrproject-rtos/zephyr/pull/49068 fixed units
displayed by the sample from dps to rad/s but did not update the
sample twister regex filter.
Fix the filter as well to allow testing in CI.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
On STM32 PM serial wakeup sample, a power efficient configuration using
lpuart is provided for stm32l562e_dk target.
Though, since default configuration of the board is using ST-Link virtual
port com on uart1, which can't be changed in CI and hence can't be tested,
then remove this target from sample yaml configuration.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
add user data for adu callback, which helps in passing
socket and relevant application parameters.
Signed-off-by: Parthiban Nallathambi <parthiban@linumiz.com>
-In order to allow non regression of trigger mode in CI, add
a dedicated configuration for this mode
-Fix regex
-Use a filter on compat rather than using a fixture
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
We auto-generate DT_COMPAT_<compat> defines so we dont need to
explicitly define them anymore.
NOTE: we need to source Kconfig.zephyr first to pull in the autogen
Kconfig.dts files.
Signed-off-by: Kumar Gala <galak@kernel.org>
Now that Wifi drivers are enabled based on devicetree we can
remove any cases of them getting enabled by *.conf files.
Signed-off-by: Kumar Gala <galak@kernel.org>
Zephyr IEEE 802.15.4 drivers and L2 stack use the same constant names
for different MTU definitions. The intent of this change is to introduce
a consistent MTU definition which can be used everywhere in zephyr to
avoid confusion, bugs and name conflict.
Signed-off-by: Florian Grandel <jerico.dev@gmail.com>
Remove the custom Kconfig value for CONFIG_SHELL_ARGC_MAX as it is too low
to account for the new arguments to the "can send" shell command.
The default for CONFIG_SHELL_ARGC_MAX was increased to 20 in
32ebeb0a5c which is sufficient for sending
non-CAN-FD format frames using the new "can send" shell command.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
