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>
Add an example of using Twister for an 'out-of-tree' application's
code coverage report generation with `--coverage-basedir` option,
and a note about `gcovr` tool possible problems with symlinks.
Fixes: #83764
Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com>
The user of the ft8xx driver can register a callback function called
on a touch detection interrupt event. This function is extended to
include a user-defined pointer. The user-defined pointer helps to share
a callback with multiple driver instances.
Signed-off-by: Hubert Miś <hubert.mis@gmail.com>
Improve the FT8xx display driver to support multiple driver instances.
The ft8xx_reference_api.h still follows the FT8xx programming guides,
limiting the usage of the driver to one instance.
Signed-off-by: Hubert Miś <hubert.mis@gmail.com>
