To disable the flash by default so the openthread RAM
settings backend is used instead.
This allows using this samples with the overlay-ot.conf
directly in the simulated nrf52_bsim.
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
k_work_* APIs cannot be used from user threads, hence it has to be
replaced with some other solution to retain userspace functionality in
the sample.
This commit reworks the sample as follows:
* Replace delayed work items with combination of k_timer and a
dedicated thread to send UDP packets. k_poll_signal is used for
communication between k_timer callback and UDP thread.
* As kernel objects should not be placed in a memory modifiable from
user threads, declare a separate structure for them, and link it
with the client context structure with a pointer.
* k_timer_init() is not a system call, therefore it has to be called
from supervisor thread. Therefore, add an additional function to
initialize UDP, and use it to initialize kernel objects used by the
UDP module and grant access for the main thread before it becomes an
user thread. UDP thread inherits permissions from the parent (main
thread).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Not all toolchains support newlib so tests that require newlib need
to have a filter to we don't try and build those tests on those
testcases. Add the following to samples.yaml to handle the issue:
filter: TOOLCHAIN_HAS_NEWLIB == 1
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
k_work_* API cannot not be used from the user threads as the APIs are
not syscalls. Doing so leads to a crash when userspace is enabled.
As the current use of delayed work API from user threads is merely
scheduling of the initial work execution, it can be moved into the main
thread context. The time difference from the former and current approach
should be marginal, as the start_tcp/udp_proto() calls are not blocking
calls.
Another issue was usage of k_mem_domain_add_thread() on uninitialized
TCP threads. This lead to another crash, as assigning thread to a memory
domain also involves removing it from the previous domain, which lead to
NULL pointer dereference if thread was not initialized yet. As, by
default, newly spawned threads inherit memory domain assignment from
their parent, it's not really needed to assign the same domain
explicitly, hence, it can be safely removed.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Adds REQUIRED to samples and tests for finding the zephyr package
to align all samples and tests with the same call and parameters.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Some features like IP fragmenting are default disabled to keep the network
stack compact for small devices.
In bigger applications as well as for the Maxwell Pro tests it required
to have the full functionality enabled. This can also work as example for
new projects.
Signed-off-by: Sjors Hettinga <s.a.hettinga@gmail.com>
The source file for most single-file sample apps is usually
`main.c`. Rename this file to be consistent with other
samples.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
* use `read()` instead of `recv()`
* use `write()` instead of `send()`
* use `CONFIG_POSIX_API` and drop `<zephyr/posix/..>` prefix
* use `perror()`
* fix `Makefile.posix` to use `CC` instead of `CXX`
* fix race condition which caused an unhandled EOF
and infinite loop, by adding a readback / echo
* Updated the docs to reflect the expected stdout
* Improve doc clarity
Signed-off-by: Chris Friedt <cfriedt@meta.com>
Recent Zephyr changes (IEEE 802.15.4 config moved from KConfig
to DeviceTree) left the TI CC1352r1_launchxl board's net examples in
a non-working state, mainly due to the fact that CC13x2 has two
IEEE802154 interfaces available (2.4GHz and sub-GHz) and none were
enabled.
This commit enables the 2.4GHz radio inside the board's DTS and also
introduces a new devicetree overlay inside the echo* samples:
'boards/boards/cc1352-enable-subg.overlay', enabling the sub-GHz
interface.
Signed-off-by: Stancu Florin <niflostancu@gmail.com>
The sample documentation mentions that the sample can be built directly
on Linux, which was no longer the case. This commit fixes it.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The old link has expired, the file is no longer avaiable to download.
Update the download link, which now leads to a file in Ubuntu
repositories for the recent LTS release, hopefully making the link valid
for longer period.
As the server ceritficate is signed by a different root CA, update the
root CA as well.
Finally, cleanup how the URL is handled in the sample - for TLS variant
it'll always be provided with a Kconfig, hence no need to repeat it in
the sample.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
It's often the case with TLS file servers, that the download link does
not lead to downloaded file, but rather redirects to another server.
Therefore it makes sense to have a minimal support in the sample for
HTTP redirection, so that the file can still be downloaded.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
This commit updates all in-tree code to use `CONFIG_CPP` instead of
`CONFIG_CPLUSPLUS`, which is now deprecated.
Signed-off-by: Stephanos Ioannidis <stephanos.ioannidis@nordicsemi.no>
Disables having USB enabled for boards that configure USB CDC for
console, shell or logging at bootup in applications that enable USB
to prevent a conflict arising whereby USB is registered from
multiple points and later calls fail.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Fix all comments-indentation errors detected by yamllint:
yamllint -f parsable -c .yamllint $( find -regex '.*\.y[a]*ml' ) | \
grep '(comments-indentation)'
This checks that the comment is aligned with the content.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.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>
Clean up occurrences of "#if IS_ENABLED(CONFIG_FOO)" an replace
with classical "#if defined(CONFIG_FOO)".
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
websocket_recv_msg() is reworked with using fsm. Now the function
return 0 when payload is empty, -ENOTCONN if socket close. Receiving
empty ping and sending empty pong were added in tests.
Fixes#52327
Signed-off-by: Grixa Yrev <grixayrev@yandex.ru>
The net_mgmt sample enables a lot of features, resulting in pretty large
image sizes for various platforms (~200k). At the same time, the
sample.yaml for the sample did not specify minimum flash requirement for
the sample, causing flash overflows during build in certain cases.
This commit fixes this by setting a reasonable flash requirement for the
sample.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
integration_platforms help us control what get built/executed in CI and
for each PR submitted. They do not filter out platforms, instead they
just minimize the amount of builds/testing for a particular
tests/sample.
Tests still run on all supported platforms when not in integration mode.
Signed-off-by: Anas Nashif <anas.nashif@intel.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>
Some minor housekeeping prior to adding an http server
implementation. There are already a number of http headers
and that number will likely increase with subsequent work.
Moving them into a common directory cleans up the
`include/net` directory a bit.
Signed-off-by: Christopher Friedt <cfriedt@meta.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>
Now that ethernet drivers are enabled based on devicetree we can
remove any cases of them getting enabled by proj.conf files.
Signed-off-by: Kumar Gala <galak@kernel.org>
Remove NET_CONFIG_IEEE802154_DEV_NAME in favor of DT based choice using
zephyr,ieee802154.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove usage of CONFIG_NET_CONFIG_IEEE802154_DEV_NAME as it now works
with DT based choice.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
All IEEE 802.15.4 drivers are now automatically enabled if they are
'okay' in DT and all of its dependencies are 'y', including
CONFIG_IEEE802154. This means individual driver enablement is not
necessary anymore in Kconfig.defconfig files or samples/tests. Boards
need to still make sure any dependencies are enabled, e.g. SPI bus in
some cases.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Use Devicetree to describe the UART UPIPE IEEE 802.15.4 driver. This
allows to remove usage of IEEE802154_UPIPE_DRV_NAME in preparation for
the removal of NET_CONFIG_IEEE802154_DEV_NAME.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
samples should not use CONFIG_TEST_EXTRA_STACK_SIZE, instead, they
should set the recommended stack size directly.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Make sure that the network interface is up before running the sample.
Otherwise, the sample could stop rightaway due to send failure.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
First off, fix the FD check when closing a socket - currently not all
sockets were closed on exit (0 is also a valid file descriptor).
Second issue is the use of k_thread_abort() on tx/rx threads. The
receving thread was blocked in recv(), and aborting its thread prevented
it from ending gracefully (i. e. the socket mutex allocated in recv()
was not released as the function did not exit properly). This resulted
on a consecutive `close()` call lock. Fix this by setting a timeout on a
receiving socket, and instead of aborting threads allowing them to exit
gracefully.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
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>
