hathach/tinyusb
1
0
Fork 0
mirror of https://github.com/hathach/tinyusb.git synced 2025-05-09 15:21:21 +08:00
Code Issues Projects Releases Wiki Activity

pre-commit fix

Browse Source
This commit is contained in:
hathach 2025-02-12 11:39:26 +07:00
parent 85247e50dd
commit 294fb268d7
No known key found for this signature in database
GPG Key ID: 26FAB84F615C3C52
6 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/class/midi/README_midi_host.md
View File

@ -51,7 +51,7 @@ pointer points to a MIDI interface descriptor, call midih_open() with that
descriptor pointer.
# CLASS SPECIFIC INTERFACE AND REQUESTS
The host driver does not make use of the informaton in the class specific
The host driver does not make use of the information in the class specific
interface descriptors. In the future, a public API could be created to
retrieve the string descriptors for the names of each ELEMENT,
IN JACK and OUT JACK, and how the device describes the connections.
@ -68,7 +68,7 @@ Descriptors. This is wrong per my reading of the specification.
# MESSAGE BUFFER DETAILS
Messages buffers composed from USB data received on the IN endpoint will never contain
running status because USB MIDI 1.0 class does not support that. Messages
buffers to be sent to the device on the OUT endpont may contain running status
buffers to be sent to the device on the OUT endpoint may contain running status
(the message might come from a UART data stream from a 5-pin DIN MIDI IN
cable on the host, for example). The driver may in the future correctly compose
4-byte USB MIDI Class packets using the running status if need be. However,

4
src/class/midi/midi_host.c
View File

@ -284,7 +284,7 @@ bool midih_open(uint8_t rhport, uint8_t dev_addr, tusb_desc_interface_t const *d
(p_mdh->bDescriptorType == TUSB_DESC_CS_ENDPOINT && p_mdh->bDescriptorSubType == MIDI_CS_ENDPOINT_GENERAL) ||
p_mdh->bDescriptorType == TUSB_DESC_ENDPOINT);
uint8_t prev_ep_addr = 0; // the CS endpoint descriptor is associated with the previous endpoint descrptor
uint8_t prev_ep_addr = 0; // the CS endpoint descriptor is associated with the previous endpoint descriptor
p_midi_host->itf_num = desc_itf->bInterfaceNumber;
tusb_desc_endpoint_t const* in_desc = NULL;
tusb_desc_endpoint_t const* out_desc = NULL;
@ -370,7 +370,7 @@ bool midih_open(uint8_t rhport, uint8_t dev_addr, tusb_desc_interface_t const *d
TU_LOG2("found CS_ENDPOINT Descriptor for %u\r\n", prev_ep_addr);
TU_VERIFY(prev_ep_addr != 0);
// parse out the mapping between the device's embedded jacks and the endpoints
// Each embedded IN jack is assocated with an OUT endpoint
// Each embedded IN jack is associated with an OUT endpoint
midi_cs_desc_endpoint_t const* p_csep = (midi_cs_desc_endpoint_t const*)p_mdh;
if (tu_edpt_dir(prev_ep_addr) == TUSB_DIR_OUT)
{

2
src/class/midi/midi_host.h
View File

@ -118,7 +118,7 @@ void midih_close (uint8_t dev_addr);
//--------------------------------------------------------------------+
// Invoked when device with MIDI interface is mounted.
// If the MIDI host application requires MIDI IN, it should requst an
// If the MIDI host application requires MIDI IN, it should request an
// IN transfer here. The device will likely NAK this transfer. How the driver
// handles the NAK is hardware dependent.
TU_ATTR_WEAK void tuh_midi_mount_cb(uint8_t dev_addr, uint8_t in_ep, uint8_t out_ep, uint8_t num_cables_rx, uint16_t num_cables_tx);