Question regarding interface numbers and tud_cdc_n_(read/write/etc) function calls

[MattMills]

Hello,

I'm trying to implement a tinyusb interface with 3 CDC devices and 1 MSC.

[snips of relevant configs]

#define CFG_TUD_CDC             (3)
#define CFG_TUD_MSC             (1)
#define USBD_ITF_CDC_STDIO      (0)
#define USBD_ITF_CDC_STDIO_DATA (1)
#define USBD_ITF_CDC_UART0      (2) 
#define USBD_ITF_CDC_UART0_DATA (3) 
#define USBD_ITF_CDC_UART1      (4) 
#define USBD_ITF_CDC_UART1_DATA (5)
#define USBD_ITF_MSC            (6)
#define USBD_ITF_MAX            (7)

I've been using these interface numbers in the first argument to the n function calls and I've been getting crashes, and reviewing the initializer for CDC here https://github.com/raspberrypi/tinyusb/blob/master/src/class/cdc/cdc_device.c#L259 and the usage within _n_read and _n_write here https://github.com/raspberrypi/tinyusb/blob/master/src/class/cdc/cdc_device.c#L169

(backtrace detail)

#0  0x100001c6 in isr_svcall ()
#1  <signal handler called>
#2  0x20000da4 in mutex_enter_timeout_ms ()
#3  0x1000899e in tu_fifo_write_n ()
#4  0x100075a8 in tud_cdc_n_write ()
#5  0x100058c2 in tumt_uart_bridge_uart1_in_out ()
#6  0x20000e6a in tumt_periodic_task ()
#7  <signal handler called>
#8  0x100010d4 in sleep_until ()
#9  0x1000113c in sleep_ms ()
#10 0x100003aa in main ()

and finally the dual port example here: https://github.com/raspberrypi/tinyusb/blob/pico/examples/device/cdc_dual_ports/src/main.c#L84

I want to ask if my understanding that the USBD_ITF numbers are NOT what should be passed to the n() functions ITF parameter, and where do I get/generate/determine those interface numbers from?

For the time being I'm just going to guess they're sequential from the ordering of CDC devices within the descriptor configuration returned by tud_descriptor_configuration_cb? Then my next question would be, if the CDC devices are not in strict order, how are they numbered (IE, if the descriptor config has CDC, MSC, MIDI, CDC, MSC, CDC).

[hathach]

all class driver API take instance ID instead of interface number. Which is zero-index and depends on the order of appearance of the interfaces within configuration. I should rename the ITF to INSTANCE to make it clearer.

Originally posted by @hathach in #1202 (reply in thread)

[Nikitarc]

I think this number is neither in ITF nor an INSTANCE but it is an index. The term 'index' or 'idx' instead of 'itf' seems more appropriate to me.

[auxym]

Just to confirm, this is the case not just for CDC, but also eg. for the instance parameter in the HID api functions?

[hathach]

yes, it is

[akohlsmith]

is there a way to retrieve the device id of a cdc (or other class) driver's instance from the host stack?

Yes there is -- use tuh_cdc_itf_get_info() -- the device id/address is in the returned struct.