Allow specifying the Kconfig file path in the environment (in practice
in the `conf.py` file), to allow the script to correctly find Kconfig
roots that aren't in the expected `"modules" / name / "Kconfig"`
location.
This is required since in the normal build system, the
`ZEPHYR_{name_var}_KCONFIG` cmake symbol can be constructed arbitrarily
in `modules.cmake`.
Signed-off-by: Jordan Yates <jordan@embeint.com>
The BLE acronym is not an official description of Bluetooth
LE, and the Bluetooth SIG only ever refers to it as Bluetooth
Low Energy or Bluetooth LE, so Zephyr should as well.
This commit does not change any board or vendor specific
documentation, and the term BLE may still be used in those.
It will be up to the vendors to update it if they want,
since many of them are using the term BLE in their
products.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Added a new function, bt_conn_is_type, that returns whether
the provided conn object is of the provided type.
This check is then used to ensure that the conn objects
supplied to other bt_conn function are of the right type.
The right type has also been documented for these functions.
This is an initial commit for a larger change in the BT Host,
as similar checks should be added to the L2CAP, GATT, ISO,
Audio and possibly Mesh APIs.
The type check could have been implemented by using the
bt_conn_get_info function, but that requires additional
function calls as well as memory allocation and copy.
Since bt_conn_is_type is designed to be widely used, it
was suited for its own function.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The Discord channel name for LE Audio has been renamed to bt-audio
The Discord channel name for bluetooth-sig has been renamed to bt-sig
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The video_stream_start/stop() APIs are counter-symetric and have
the same function signature. Also, the implementation logic for
those driver APIs is generally the same. Merge them to save memory
and code lines.
For the sake of simplicity, still keep the user APIs to preserve
backward compatibility with downstream applications.
Signed-off-by: Phi Bang Nguyen <phibang.nguyen@nxp.com>
Adds details on how to select this new operating mode when using
and when not using sysbuild, also includes a note about a Kconfig
being deprecated and the name of the replacement symbol
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
This commit updates the SMP section documentation so that it reflects the
current status of SMP support in Zephyr for RISC-V, including pointing to
hardware-based platforms that as of date support SMP.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Commit adds description of key representation incompatibility
for mesh images built with different crypto libraries.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
Follow-up on newly introduced USB MIDI2 support.
Prefix with usbd_, use midi2 consistently.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Add wsen_pads_2511020213301 driver with
the corrected name and compatibility with
the hal update as well as added new features.
Signed-off-by: Wajdi ELMuhtadi <wajdi.elmuhtadi@we-online.com>
Both backends supported as runners for nRF ICs, nrfjprog and nrfutil,
support erasing external memory as part of the programming operation.
Before this patch, and when the firmware was detected to be partially or
fully placed in external flash by inspecting the .hex address range, the
runner would instruct the backend tool to fully erase the external
flash (but the nrfjprog runner would ignore that, always erasing only
the sectors required). Instead, correctly default to erasing only the
sectors that are required to program the new firmware image in both tools,
and erase it completely only when the --erase flag is provided by the user.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Since a separate CONFIG_NET_TC_RX_SKIP_FOR_HIGH_PRIO was introduced for
RX TC queues, CONFIG_NET_TC_SKIP_FOR_HIGH_PRIO became ambiguous,
rename it to CONFIG_NET_TC_TX_SKIP_FOR_HIGH_PRIO and deprecate the old
config.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The Nordic nRF52 series have a peculiarity that is not shared with any
other Nordic families of SoCs: the reset pin can be reconfigured as a
regular GPIO. This has an unintended consequence: if the user has
reconfigured the pin in Devicetree to be a GPIO, `west flash` will
override that and configure the IC to use it as a reset pin, and the
firmware at boot won't be able to switch it back to GPIO, because that
requires a UICR erase. This behavior is very confusing to users, because
the GPIO does not work at all, since it is now just a reset line.
With this patch, `west flash` defaults to using soft reset instead of
pin reset for the nRF52 family of devices, to avoid overwriting the
reset pin configuration that the user includes in the image.
In order to be able to continue to use pin reset for users that so
desire it, a new option `--pinreset` is added that forces the use of pin
reset. The existing `--softreset` option is left exactly as it was, but
it is now applicable only to families other than the nRF52.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The way the instructions were formulated, it was possible for someone to
get the impression that only a specific name of the workspace is allowable.
Clarify that the name and location can be freely chosen.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
This new implementation is written from scratch and is not tied to the
image manager and MCUboot. It allows the user to define their own
backend and use a simple macro to instantiate an image. On the USB side
this is represented by an interface. The number of possible images is
configurable using the Kconfig option, and is a fairly inexpensive
approach since it only changes the size of the pointer array. The number
of images is only limited by the number of possible interfaces in a
configuration. The class implementation does not support multiple
instances, as there is no real use for it. However, it does provide two
class instances, one for runtime mode and one for DFU mode. The switch
from runtime to DFU mode can only be performed by the user application,
i.e. the application receives a notification when the host wants to
switch to DFU mode, and then the application can disable the runtime
configuration and enable the DFU configuration. This implementation does
not support switching to the DFU mode by bus reset issued by the
host.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Under the documentation generation sections, the path to the docs folder
and the zephyr path is inconsistent with the getting started pages.
Update to match
Signed-off-by: Mihira Madhava Bollapragada <madhava@ti.com>
Mark the XSI_REALTIME Option Group as supported, such that the
_XOPEN_REALTIME feature test macro may be tested.
Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
This adds a new USB device class (based on usb/device_next) that implements
revision 2.0 of the MIDIStreaming interface, a sub-class of the USB audio
device class. In practice, the MIDI interface is much more simple and has
little in common with Audio, so it makes sense to have it as a separate
class driver.
MIDI inputs and outputs are configured through the device tree, under a
node `compatible = "zephyr,usb-midi"`. As per the USB-MIDI2.0 spec,
a single usb-midi interface can convey up to 16 Universal MIDI groups,
comprising 16 channels each. Data is carried from/to the host via
so-called Group Terminals, that are organized in Group Terminal Blocks.
They are represented as children of the usb-midi interface in the device
tree.
From the Zephyr application programmer perspective, MIDI data is exchanged
with the host through the device associated with the `zephyr,usb-midi`
interface, using the following API:
* Send a Universal MIDI Packet to the host: `usb_midi_send(device, pkt)`
* Universal MIDI Packets from the host are delivered to the function passed
in `usb_midi_set_ops(device, &{.rx_packet_cb = handler})`
Compliant USB-MIDI 2.0 devices are required to expose a USB-MIDI1.0
interface as alt setting 0, and the 2.0 interface on alt setting 1.
To avoid the extra complexity of generating backward compatible USB
descriptors and translating Universal MIDI Packets from/to the old
USB-MIDI1.0 format, this driver generates an empty MIDI1.0 interface
(without any input/output); and therefore will only be able to exchange
MIDI data when the host has explicitely enabled MIDI2.0 (alt setting 1).
This implementation is based on the following documents, which are referred
to in the inline comments:
* `midi20`:
Universal Serial Bus Device Class Definition for MIDI Devices
Release 2.0
https://www.usb.org/sites/default/files/USB%20MIDI%20v2_0.pdf
* `ump112`:
Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol
With MIDI 1.0 Protocol in UMP Format
Document Version 1.1.2
https://midi.org/universal-midi-packet-ump-and-midi-2-0-protocol-specification
Signed-off-by: Titouan Christophe <moiandme@gmail.com>
Consolidate all style guidelines into one place, moving cmake style
guidelines under the contribute section.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Similar to how we have a button in code samples' READMEs,
this helps direcly taking the reader to the board's sources
on GitHub
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
