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>
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>
Add initial HID device support. Unlike the existing HID implementation,
the new implementation uses a devicetree to instantiate a HID device.
To the user, the HID device appears as a normal Zephyr RTOS device.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Introduce new USB Audio 2 implementation written from scratch. Main goal
behind new implementation was to perform entity configuration with
devicetree bindings, hiding the descriptor complexity from application.
Initial implementation is working at Full-Speed only. High-Speed support
will come later, but even at Full-Speed only this is viable replacement
for old stack USB Audio 1 class (USB Audio 1 is limited to Full-Speed by
specification, i.e. it is explicitly forbidden for USB Audio 1 device to
work at High-Speed).
Implemented is only absolute minimum set of features required for basic
implicit and explicit feedback samples. Only one sample frequency is
currently supported. Optional interrupt notifications are not supported.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
Add CDC Ethernet Control Model class implementation for the
new experimental USB device support based on the existing
implementation subsys/usb/device/class/netusb/function_ecm.c.
The implementation forms virtual ethernet connection between
USB host and USB device and requires two corresponding MAC
addresses, one for the virtual interface on the device side,
and other for the host which is described by a string descriptor.
With upcoming changes it should also possible to use a real
ethernet controller as media access on the device side.
CDC ECM implementation supports multiple instances which are
specified using DT. The number of instances is limited by the
number of endpoints on the controller, two to three should usually
be possible.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Introduce new USB Mass Storage Bulk-Only Transport implementation
written from scratch. Main goal behind new implementation was to
separate USB and SCSI parts as clearly as possible.
Limited set of SCSI disk commands is implemented in separate source code
file that is internal to USB device stack. While it should be possible
to use the SCSI implementation by other components there is currently no
other user besides USB MSC and therefore SCSI header is kept private.
Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
Add Bluetooth HCI USB transport layer implementation for the new
experimental USB device support based on the existing implementation
subsys/usb/device/class/bluetooth.c.
This implementation, unlike existing one, contains the interface
descriptors for isochronous endpoints. Since we do not support voice
channels, these are just there to avoid issues with Linux kernel btusb
driver when this implementation is part of a composite configuration.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Add experimental CDC ACM implementation for new USB device stack.
It currently implements only UART IRQ API support and is WIP.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
The device supprt brings support for multiple stack instances,
multiple configuration, asynchronous transfer model, ability to
change most of the properties of a device at runtime and
the composition of configuration and classes at runtime.
The stack requires new UDC driver API and is not compatible
with old driver API (usb_dc_). The classes (functions) of old
(current) USB device stack cannot be used with new ones and must
be ported.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
