This updates the documentation of all the STM32 boards to use
the new `zephyr:board::` directive.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
The native_posix compilations fail with various socket
errors like this:
samples/net/sockets/can/src/main.c:65:9: error: implicit \
declaration of function ‘send’ [-Werror=implicit-function-declaration]
65 | ret = send(fd, &sframe, sizeof(sframe), 0);
| ^~~~
So disable the native_posix board from networking samples as
native_posix board is not compatible with CONFIG_POSIX_API
This is related to commit b8fc1c4c3e ("samples: net: Disable
native_posix target in samples") but disables more network samples
for native_posix board.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
If enabling CONFIG_POSIX_API, we get three file descriptors open
before any socket descriptors. The sample exit criteria checks
socket 0 and 1 which is no longer a valid one, so change the
check to be either 0 or 3, and 1 or 4 so that the test can be
run in both when POSIX API is enabled or disabled.
Also disable color printing for the test run so that it is
easier to read the output log.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Change the sample applications that use network socket API to
use the POSIX_API config because the NET_SOCKETS_POSIX_NAMES is
deprecated. Convert also the zsock_ API calls to plain BSD
socket API calls when applicable.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
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>
Use the new code-sample directive and roles to document the networking
samples so that they show up as "Related samples" when browsing the
various relevant networking APIs.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
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>
As both C and C++ standards require applications running under an OS to
return 'int', adapt that for Zephyr to align with those standard. This also
eliminates errors when building with clang when not using -ffreestanding,
and reduces the need for compiler flags to silence warnings for both clang
and gcc.
Most of these changes were automated using coccinelle with the following
script:
@@
@@
- void
+ int
main(...) {
...
- return;
+ return 0;
...
}
Approximately 40 files had to be edited by hand as coccinelle was unable to
fix them.
Signed-off-by: Keith Packard <keithp@keithp.com>
Fix all thruthy errors detected by yamllint:
yamllint -f parsable -c .yamllint $( find -regex '.*\.y[a]*ml' ) | \
grep '(truthy)'
This only accepts true/false for boolean properties. Seems like python
takes all sort of formats:
https://github.com/yaml/pyyaml/blob/master/lib/yaml/constructor.py#L224-L235
But the current specs only mention "true" or "false"
https://yaml.org/spec/1.2.2/#10212-boolean
Which is the standard yamllint config.
Excluding codeconv and workflow files, as some are using yes/no instead
in the respective documentation.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Skip all CAN controller tests utilizing CAN loopback mode for the
kvaser,pcican CAN controller card as emulated in QEMU.
QEMU emulation of the SJA1000 CAN controller backend does not yet support
the SJA1000 Self Reception Request command which is required for proper
loopback operation.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
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 .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>
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>
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 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>
Decouple the zephyr/net/socketcan.h and zephyr/drivers/can.h header files
by moving the SocketCAN utilities to their own header.
This is preparation for including the SocketCAN types defined in
socketcan.h in a native posix (Linux) SocketCAN driver context without name
clashes.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the SocketCAN header from socket_can.h to socketcan.h to better
match the naming of the functionality.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Rename the SocketCAN utility functions to reflect the new naming of the CAN
controller API and SocketCAN API data types.
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>
Rename the SocketCAN data types to "socketcan_*" in preparation of renaming
the low-level CAN controller API data types.
This breaks the naming compatibility with the similar SocketCAN data types
from the Linux kernel, but Zephyr and Linux SocketCAN are not 100%
compatible anyways (only the structure fields are compatible, extended
functionality such filtering, error reporting etc. are not).
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Add support for running the SocketCAN sample on
native_posix/native_posix_64 using the CAN loopback interface.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
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 samples to the use
the new prefix <zephyr/...>. Note that the conversion has been scripted:
```python
from pathlib import Path
import re
EXTENSIONS = ("c", "h", "cpp", "rst")
for p in Path(".").glob("samples/**/*"):
if not p.is_file() or p.suffix and p.suffix[1:] not in EXTENSIONS:
continue
content = ""
with open(p) as f:
for line in f:
m = re.match(r"^(.*)#include <(.*)>(.*)$", line)
if (m and
not m.group(2).startswith("zephyr/") and
(Path(".") / "include" / "zephyr" / m.group(2)).exists()):
content += (
m.group(1) +
"#include <zephyr/" + m.group(2) +">" +
m.group(3) + "\n"
)
else:
content += line
with open(p, "w") as f:
f.write(content)
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Add loopback mode config to the sample so that the code
can be tested without an actual CAN network, but wit a
single board.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
- Filter out the remaining CAN tests if no zephyr,canbus chosen node is
enabled in the devicetree.
- Rename the tests to shorten the name a bit.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Disable Ethernet on SocketCAN sample because some Ethernet
drivers cannot operate on such small buffers.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
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>
socket_can_generic.h makes some assumptions that are not always valid
for various drivers with regards to numbering. To clean this up we
add defines for SOCKET_CAN_NAME_0 and SOCKET_CAN_NAME_2 in addition to
SOCKET_CAN_NAME_1.
We also move struct socket_can_context into the drivers themselves
since they know best how many CAN interfaces are getting supported and
what naming/number convention they'd have.
Additionally, this also exposes a few other build issues with the
can_mcux_flexcan driver that get fixed.
Finally, we remove the platform_allow from samples/net/sockets/can
since it is no longer needed.
Fixes#31733
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Clean up logging menuconfig by grouping configuration into
sections like: mode, processing configuration, backends.
Additionlly, removed LOG_ENABLE_FANCY_OUTPUT_FORMATTING which is no
longer in use.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Reordering of the struct elements to match the Linux format.
The __packed() is not necessary anymore.
std_id and ext_id is merged to id in the frame and filter.
Additionally, the frames are ready for CAN-FD.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
This provides a better error message when building with CMake and
forgetting ZEPHYR_BASE or not registering Zephyr in the CMake package
registry. See parent commit for more details (split from parent for
better readability).
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Convert all canbus related API/samples/tests/subsys
to the new timeout API with k_timeout_t.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
Using find_package to locate Zephyr.
Old behavior was to use $ENV{ZEPHYR_BASE} for inclusion of boiler plate
code.
Whenever an automatic run of CMake happend by the build system / IDE
then it was required that ZEPHYR_BASE was defined.
Using ZEPHYR_BASE only to locate the Zephyr package allows CMake to
cache the base variable and thus allowing subsequent invocation even
if ZEPHYR_BASE is not set in the environment.
It also removes the risk of strange build results if a user switchs
between different Zephyr based project folders and forgetting to reset
ZEPHYR_BASE before running ninja / make.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This commit is an implementation of 6LoCAN, a 6Lo adaption layer for
Controller Area Networks. 6LoCAN is not yet standardised.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
This is done only for testing purposes, in real life the socket
would be closed if it is not used or needed.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
