mirror of
https://github.com/hathach/tinyusb.git
synced 2025-05-09 07:11:16 +08:00
pre-commit fix
This commit is contained in:
parent
85247e50dd
commit
294fb268d7
@ -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})
|
||||
|
@ -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
|
||||
|
@ -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;
|
||||
}
|
||||
}
|
||||
|
@ -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.
|
||||
|
@ -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)
|
||||
{
|
||||
|
@ -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);
|
||||
|
Loading…
x
Reference in New Issue
Block a user