В стандарте и конечно же в PC-ОСях такое реаизовано? Нужно чтобы одно из соединений композита продолжало работать без запинок/переинициализаций, а другие могли подключиться или отключиться. Вариант с полным отключением девайса не годится. Пока что-то похожее видится через имитацию хаба и независимые друг от друга дескрипторы, но это сложный вариант по сравнению с просто сменой дескрипторов и внутренней логики обработчиков эндпоинтов.

Интересный вопрос. Однако, имитация хаба в данном случае самое лучшее, имхо, ведь для прочтения нового набора дескрипторов нужна ренумерация, т.е. переподключение устройства.

Не вполне понимаю, что именно нужно ТС, но есть подозрение, что решением является использование Alternate Setting для интерфейсов.

Есть один микроконтроллер, один комп и один кабель между ними. Нужно чтобы микроконтроллер/девайс в любой момент работы компа без перетыканий кабеля или электрической имитации переподключения мог менять кол-во своих интерфейсов. Все интерфейсы стандартных классов со встроенными в ось драйверами. Допустим MSC, CDC, HID в любом количестве (на что хватит железа проца). Исходя из этого Alternate Setting не подходит, т.к.


Отключать часть интерфейсов нужно обязательно, т.к. обмен данными будет недоступен. И любое ПО компа должно это видеть. Вариант с постоянным присутствием всех интерфейсов поэтому не годится.

Теперь понятно. Насколько мне известно, такого механизма нет.

Не заложено или не реализовано?


Композит похож на хаб наличием разнородных интерфейсов, очевидно независимых друг от друга на стороне хоста. Нормально было бы применять к нему похожую логику работы ПО хоста. Если не реализовали, то жаль конечно. Если сделать хост на другом микроконтроллере, то горячее изменение кол-ва интерфейсов вероятно можно реализовать. Но если этот хост потом воткнуть девайсом в комп, то возникнет проблема из абзаца ниже. То есть её решить можно только принципом гоячих изменений конфигурации/дескрипторов.

При отключении части интерфейсов даже имена дисков и ком-портов корректно сохранялись бы и у активых и у вновь появившихся благодаря полю bInterfaceNumber. А у (имитации) хаба такой возможности нет. Хотя, если ОС при обнаружении подключения к хабу видит физический номер его порта, а не оперирует только назначенным адресом, то это даст возможность корректно сохранять идентификаторы интерфейсов и в имитации хаба.

Оптимальнее было бы заложить в атрибуты дескриптора устройства (не интерфейса) флаг динамической/горячей конфигурации чтобы не тратить ресурсы на опрос девайсов с жёсткой конфигурацией. Мечты, мечты...

Неужели хабом "прикинуться" из вариантов NXP можно только на линейках LPC18xx & LPC43xx, которые единственные в режиме USB-device умеют принимать данные для любых адресов (функций) ? У других линеек либо конкретный адрес, либо 0 & EP=0.

С чего Вы взяли?
LPC в режиме device нормально проходят фазу установки адреса. Иначе это был бы не USB-device.

Через какой адрес и эндпоинт?

ЗЫ
"либо конкретный адрес" понимать нужно как адрес после энумерации (фазы установки адреса). То есть пакеты к одому единственному адресу процессором принимаются, а остальные улетают "мимо" процессора.