pre-commit fix

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

View File

@ -24,4 +24,4 @@ target_include_directories(${PROJECT} PUBLIC
# Configure compilation flags and libraries for the example... see the corresponding function
# in hw/bsp/FAMILY/family.cmake for details.
family_configure_host_example(${PROJECT})
family_configure_host_example(${PROJECT})

View File

@ -6,4 +6,4 @@ INC += \
# Example source
EXAMPLE_SOURCE += $(wildcard src/*.c)
SRC_C += $(addprefix $(CURRENT_PATH)/, $(EXAMPLE_SOURCE))
include ../../rules.mk
include ../../rules.mk

View File

@ -157,4 +157,4 @@ void tuh_midi_rx_cb(uint8_t dev_addr, uint32_t num_packets)
void tuh_midi_tx_cb(uint8_t dev_addr)
{
(void ) dev_addr;
}
}

View File

@ -9,7 +9,7 @@ constraint may change in the future.
# MAXIMUM NUMBER OF ENDPOINTS
Although the USB MIDI 1.0 Class specification allows an arbitrary number
of endpoints, this driver supports at most one USB BULK DATA IN endpoint
and one USB BULK DATA OUT endpoint. Each endpoint can support up to 16
and one USB BULK DATA OUT endpoint. Each endpoint can support up to 16
virtual cables. If a device has multiple IN endpoints or multiple OUT
endpoints, it will fail to enumerate.
@ -51,9 +51,9 @@ 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,
retrieve the string descriptors for the names of each ELEMENT,
IN JACK and OUT JACK, and how the device describes the connections.
This driver also does not support class specific requests to control
@ -68,18 +68,18 @@ 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
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,
it does not currently do that. Also, use of running status is not a good idea
overall because a single byte error can really mess up the data stream with no
way to recover until the next non-real time status byte is in the message buffer.
Message buffers to be sent to the device may contain Real time messages
such as MIDI clock. Real time messages may be inserted in the message
such as MIDI clock. Real time messages may be inserted in the message
byte stream between status and data bytes of another message without disrupting
the running status. However, because MIDI 1.0 class messages are sent
the running status. However, because MIDI 1.0 class messages are sent
as four byte packets, a real-time message so inserted will be re-ordered
to be sent to the device in a new 4-byte packet immediately before the
interrupted data stream.

View File

@ -1,4 +1,4 @@
/*
/*
* The MIT License (MIT)
*
* Copyright (c) 2019 Ha Thach (tinyusb.org)
@ -76,7 +76,7 @@ typedef struct
// Endpoint FIFOs
tu_fifo_t rx_ff;
tu_fifo_t tx_ff;
uint8_t rx_ff_buf[CFG_TUH_MIDI_RX_BUFSIZE];
uint8_t tx_ff_buf[CFG_TUH_MIDI_TX_BUFSIZE];
@ -280,17 +280,17 @@ bool midih_open(uint8_t rhport, uint8_t dev_addr, tusb_desc_interface_t const *d
// assume it is an interface header
midi_desc_header_t const *p_mdh = (midi_desc_header_t const *)p_desc;
TU_VERIFY((p_mdh->bDescriptorType == TUSB_DESC_CS_INTERFACE && p_mdh->bDescriptorSubType == MIDI_CS_INTERFACE_HEADER) ||
TU_VERIFY((p_mdh->bDescriptorType == TUSB_DESC_CS_INTERFACE && p_mdh->bDescriptorSubType == MIDI_CS_INTERFACE_HEADER) ||
(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;
while (len_parsed < max_len)
{
TU_VERIFY((p_mdh->bDescriptorType == TUSB_DESC_CS_INTERFACE) ||
TU_VERIFY((p_mdh->bDescriptorType == TUSB_DESC_CS_INTERFACE) ||
(p_mdh->bDescriptorType == TUSB_DESC_CS_ENDPOINT && p_mdh->bDescriptorSubType == MIDI_CS_ENDPOINT_GENERAL) ||
p_mdh->bDescriptorType == TUSB_DESC_ENDPOINT);
@ -306,7 +306,7 @@ bool midih_open(uint8_t rhport, uint8_t dev_addr, tusb_desc_interface_t const *d
}
else if (p_mdij->bDescriptorSubType == MIDI_CS_INTERFACE_IN_JACK)
{
// Then it is an in jack.
// Then it is an in jack.
TU_LOG2("Found in jack\r\n");
#if CFG_MIDI_HOST_DEVSTRINGS
if (p_midi_host->next_in_jack < MAX_IN_JACKS)
@ -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)
{

View File

@ -1,4 +1,4 @@
/*
/*
* The MIT License (MIT)
*
* Copyright (c) 2019 Ha Thach (tinyusb.org)
@ -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);