Коллега, я Вас услышал, и вот моё резюме:
1) CDC могут работать как составные (composite) устройства, вывешивая на хост символьный интерфейс для команд и пакетный интерфейс для коммуникационных протоколов канального уровня типа Ethernet, PPP, работающий в крупноблочном (bulk) режиме. Это типовая реализация USB-свистков 3G/4G (там ещё Mass Storage с драйверами в нагрузку идёт).
2) В самой идее HID есть *готовые* абстракции для описания наборов сенсоров, датчиков, индикаторов и прочего. В CDC нет, это чистые коммуникации (дать сырой символьный или пакетный интерфейс хосту).
3) Моей HID-кофеварке бешеные потоки данных не нужны, и пересборка пакетов волнует не с точки зрения производительности (ARM и не поперхнётся). Обмен короткими (не bulk), бинарно-ориентированным структурами данных (пульты, датчики, сенсоры и прочее) потребует либо адаптации символьного интерфейса на пакетный режим (нежелательная пересборка), либо адаптации bulk transfer к коротким передачам определённого формата, укладываемым строго в виде сообщение-пакет, без разбивки/пересборки.
4) Вариант с использованием упомянутого канала bulk transfer в пакетном режиме для моей кофеварки интересен, но готового примера именно такой реализации для ARM Вы пока не предложили, упоминая только символьный протокол. Этот вопрос остаётся открытым.
5) На символьных протоколах работает невероятное количество всяких устройств, в основном, старых. Я хочу пакетной новизны, и у меня есть готовый и работающий (не под всеми платформами одинаково хорошо) пример кода с HID.
6) Получается, что от библиотек и middleware зависит почти всё. Есть и хорошие библиотеки для пакетных кодеков, и плохие для USB HID, и наоборот.
Так что если хорошего примера кода с библиотекой по п. 4 нет, давайте просто не будем мусолить тему по кругу:)
1) CDC могут работать как составные (composite) устройства, вывешивая на хост символьный интерфейс для команд и пакетный интерфейс для коммуникационных протоколов канального уровня типа Ethernet, PPP, работающий в крупноблочном (bulk) режиме. Это типовая реализация USB-свистков 3G/4G (там ещё Mass Storage с драйверами в нагрузку идёт).
2) В самой идее HID есть *готовые* абстракции для описания наборов сенсоров, датчиков, индикаторов и прочего. В CDC нет, это чистые коммуникации (дать сырой символьный или пакетный интерфейс хосту).
3) Моей HID-кофеварке бешеные потоки данных не нужны, и пересборка пакетов волнует не с точки зрения производительности (ARM и не поперхнётся). Обмен короткими (не bulk), бинарно-ориентированным структурами данных (пульты, датчики, сенсоры и прочее) потребует либо адаптации символьного интерфейса на пакетный режим (нежелательная пересборка), либо адаптации bulk transfer к коротким передачам определённого формата, укладываемым строго в виде сообщение-пакет, без разбивки/пересборки.
4) Вариант с использованием упомянутого канала bulk transfer в пакетном режиме для моей кофеварки интересен, но готового примера именно такой реализации для ARM Вы пока не предложили, упоминая только символьный протокол. Этот вопрос остаётся открытым.
5) На символьных протоколах работает невероятное количество всяких устройств, в основном, старых. Я хочу пакетной новизны, и у меня есть готовый и работающий (не под всеми платформами одинаково хорошо) пример кода с HID.
6) Получается, что от библиотек и middleware зависит почти всё. Есть и хорошие библиотеки для пакетных кодеков, и плохие для USB HID, и наоборот.
Так что если хорошего примера кода с библиотекой по п. 4 нет, давайте просто не будем мусолить тему по кругу:)