Посоветуйте путь наименьшего сопротивления реализации данного девайса.
Есть CY7C68013A, к нему подключена ПЛИС, которая висит на шине PCI процессора RDC R8610. Процессор имеет MAC-контроллер, который совместно с микросхемой физического уровня образует шину Fast Ethernet для подключения к локальной сетки.

Сначала была мысль использовать класс CDC Ethernet Emulation Model (EEM). Разбором пакетов EEM занимается RDC. А контроллер CY7C68013A по сути кладет данные в FIFO, а ПЛИС их забирает в режиме Master FIFO.

Потом наскочил на такую весчь, как Remote Network Driver Interface Specification (RNDIS). Спецификация обеспечивает поддержку сетевых устройств с различными шинами, в том числе и USB.

Есть ли принципиальные преимущества и недостатки этих спецификаций в сравнении. Хотелось бы пообщаться с теми, кто имеет опыт в этих делах. Какие подводные камни ожидают в первом и во-втором случае?

Считается, что по такому пути сделать устройство проще и оно будет более строго соответствовать спецификации USB. Единственный минус - я не смог найти штатного драйвера для Windows. Если кто-то сможет подсказать вариант - буду благодарен.


RNDIS - сугубо майкрософтовская придумка, причем, изначально идея была гораздо шире чем только реализация сети по USB - там много интерфейсов перечислено - FireWire и прочие. Как я понял, на USB пока все и закончилось. Реализовать устройство немного сложнее, но, начиная с Windows 2000 есть штатный драйвер RNDIS для USB. Причем - есть где подсмотреть обмен и раскрыть недокументированные неясности - WinCE смартфоны и наладонники подключаются к ПК по RNDIS - это также внушает надежду что RNDIS поддерживаться будет еще долго. Начиная с Висты - драйвер сразу идет в комплекте - его не надо даже устанавливать специально.

Про "подводные камни" пока много не расскажу - сам только начал controlplane ковырять, но тут на форуме есть люди которые успешно RNDIS реализовали, думаю, если будет нужна консультация - помогут.

А стандартный драйвер системы usbser.sys не реализует в себе работу с классом CDC Ethernet Emulation Model (EEM)?
Я полагаю, что EEM по спецификации является подклассом класса Communications Device Class. Значит драйвер для CDC также реализует поддержку EEM протокола.
Кто-нибудь проверял это?

А почему не хотите воспользоваться аппаратным конвертером, например Realtek, или нужна обработка пакетов?

Маловероятно. Если драйвер это делал бы, то у него в теле файла ссылки на функции NDIS были бы, а таковых нет

Во-первых, планирую забацать композитный девайс, который будет включать два интерфейса: Mass Storage Device и CDC Ethernet Emulation Model. На счет второго правда сейчас неясности со стандартным драйвером в винде. Есть он или нет? Альтернативный вариант заюзать механизм обмена через USB с локальной сеткой по спецификации Remote NDIS.
Во-вторых, пакеты будет разбирать ПЛИС и направлять их либо в сеть ethernet либо на USB флэшку.



Хренова
А кроме спецификации RNDIS и CDC EEM есть ещё варианты сделать сетевое устройство USB с использованием стандартного драйвера?

Готовое устройство стоит примерно 8$, есть смысл его разрабатывать заново?

Еще рассматривался вариант эмуляции какого-нибудь готового USB->EMAC чипа, типа MosCHIP MCS7830. И драйвера к нему есть, и даже программа адаптации для OEM-производителей - можно свои названия в драйвер прикрутить. Но мне показалось, что там возни больше чем с RNDIS.

И Вот наступил 17-й год...

Выяснилось, что W10 поддерживает CDC EEM (но не CDC ECM) и CDC ACM последовательные порты "из коробки".

Сообщение отредактировал Genadi Zawidowski - Jan 8 2017, 19:06

Есть проблема...
В составном устройстве (CDC ACM + CDC EEM) все нормально. По одиночке все варианты (IAD + звук, пара CDC, ECM без драйвера) опознаются нормально.
CDC EEM в одиночку говорит что не может запуститься, необработанных запросов по EP0 нет (кроме device qualifier, но и это не помогает). При этом составное устройство (в ветке device manager-а USB Controllers) не появляется, в отличии от всех остальных случаев.
Наличие/отсутствие Interface Association Descriptor в функции на поведение не влияет. Если CDC EEM стоит первым в "компании" с чем-то другим, тоже всё работает. Не работает в одиночку.
Что-нибудь сказать можно? Вот дамп дескрипторов.

Сообщение отредактировал Genadi Zawidowski - Jan 10 2017, 02:31

err

Сообщение отредактировал Genadi Zawidowski - Jan 10 2017, 02:28

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

Ещё вопрос. Движок энумерации универсальный - на все случаи жизни, или же изначально он работал только с одним из устройств, которые комбинируются?

Универсальный. Дамп комбинированного устройства выше приложен. Работают все варианты (разумеется, речь об енумерации, на все варианты ендпоинтов не хватит). И по одному все. Только CDC EEM такой особенный...
Вот исходники в аттачменте, если что отсюда https://188.134.5.254/browser/hfreceiver/tr...bd_desc.c#L1576 - смотреть со строки 1576.
Не, с длинами в дескрипторах всё решено, дескрипторы создаются с автоматическим подсчётом размеров.

Сообщение отредактировал Genadi Zawidowski - Jan 10 2017, 09:17

Может существует у кого-нибудь дескриптор устройства с единственным CDC EEM, которое (устройство) нормально работает? Например какой-нибудь USB dongle..

Я нашёл два отличия в дампах для комбинированного устройства, и для единственного.
1. Для единственного устройства в "Device Descriptor", там где ссылки на строковые дескрипторы (смещ. 14,15,16) - не показаны строки, на которые идёт ссылка. Может их нет в списке дескрипторов?
А у комбинированного устройства, строчки в этих позициях показаны... Может это что-то значит?
Если винда не находит строковые дескрипторы, когда они должны быть - она энумерацию не закончит. Или там нужно нолики поставить, или проверить наличие строковых дескрипторов с номерами 01, 02, 03.

2. Единственное устройство работает с EP1 (In/Out), а комбинированное с EP2 (тоже In/Out). Посмотрите, может программа единственного устройства не сконфигурировала EP1, а по прежнему конфигурирует EP2? Или не сами EndPoint-ы, а их прерывания не сконфигурированны (должны быть разрешены EP1, а разрешено EP2).

Сообщение отредактировал controller_m30 - Jan 10 2017, 10:50