Посоветуйте путь наименьшего сопротивления реализации данного девайса.
Есть 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 последовательные порты "из коробки".

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

err

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

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

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

Может существует у кого-нибудь дескриптор устройства с единственным 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).

Да это странности USBLyzer-а.
Ендпоинты конфигурируются... ПРосто с нестартующим устройством до них (кроме нулевого) не доходит дело.

...

Забил все строковые дескрипторы для ясности нулями.
ПОведение не поменялось - нестартующий единственный CDC EEM и нормально работающие остальные варианты.
Даже такой как непоставившийся драйвер CDC-ECM и работающий при этом CDC-EEM. Непоказывающийся MAC в ECM это тоже глюк USBLYZER

Может VID или PID поменять? Например те VID и PID которые есть, вызывают драйвер, которому единственное устройство EEM не нравится... Попробуйте заменить их, чтоб винда заново драйвер для устройства поставила.
Или, если не менять VID/PID - удалить драйвер комбинированного устройства, и попробовать поставить с теми-же VID/PID устройство единственное. Может винда чего напишет новое.

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

Менять vid/pid пробовал... Но это и не нужно - драйвер нашелся, в диагностике написано что запустить не может.

Попробуйте в "Device Descriptor" для единственного устройства, в полях Class, Subclass, Protocol, поставить значения:
02, 06, 00
02, 06, 01
02, 00, 00
02, 00, 01
Вдруг какое-то заработает.

02, 06, 00 предлагают для ECM на MSDN https://msdn.microsoft.com/en-us/library/wi...7(v=vs.85).aspx

02, 00, 00 на каких-то сайтах про ECM https://sourceforge.net/p/contiki/mailman/message/25268923/
https://www.xmos.com/download/private/AN001...2.0.2rc1%29.pdf
Но если EEM работает на дескрипторах ECM, то можно значит пробовать и с другими настройками ECM что-то подбирать для EEM.

xx, xx, 01 это мой вариант для сохранения "Interface Association Descriptor", который вроде бы и не влияет, но вдруг.

EEM работает на дескрипторах EEM. Не ECM. Если я получу устройство ECM (которое хоть и без драйвера, но опознается корректно - в device manager соответствующее composite device появляется, в отличии от EEM одиночного) - что толку? Тем более, что дескриптор EEM сильно от ECM отличается - в ECM два интерфейса, например вместо одного у EEM. В той строке на которую я сослался в своих исходниках, видно все функции, которые могут поддерживаться в enumerate.

Согласен. Но поскольку вы используете Class, SubClass от ECM для EEM (0xef, 02) - значит можно для EEM попробовать и другие допустимые для ECM значения Class, SubClass. По моему логично.

Согласен полностью. Но т.к. работающие комбинированные интерфейсы начинаются с Class 0xef (miscellaneous), и в принципе так и должно быть, раз "замешано" несколько устройств, то может быть для единственного EEM нужен простой Class?

Пока ищутся оригинальные дескрипторы EEM, можно попробовать подобрать свои варианты (если они хоть как-то логически обоснованы)

0xef, 02, 0x01 - это означает, что информация о классах берется не из device descriptor, а устройство составное, в нем много разных функций может быть... Эти значения и для аудио и для компортов...


А почему он не нужен для единственного компорта (было), аудиоустройства, ECM наконец?

В аттачменте документ с картинками про составные устройства.

На сайте MSDN если (я правильно понял), как раз для ECM и предлагается 02, 06, 00. Если конечно ECM и ENCM это одно и то же.

Вот ещё вариант. В этот раз точно для EEM http://www.usb.org/developers/docs/devclas...s/CDC_EEM10.pdf
стр.13-14, Class, SubClass, Protocol: 02, 0x0C, 07

Класс/подкласс и протокол в случае составного устройства берутся оттуда, где им и положено быть - или из interface association descriptor каждой функции или из interface descriptor функции с одним интерфейсом (вольный пересказ документа).
Жаль, что DiMonster последний раз был тут



А я какой еще мог использовать, как не этот?

Да. Но вы же делаете из составного устройства простое, в случае с единственным EEM. Наверное для него нужен и дескриптор простого устройства (хотя бы Device Descriptor). Почему бы нет?
Для простых устройств можно указывать Class, Subclass, Protocol прямо в "Device Descriptor".

Нет, это составное устройство с одной функцией. Работает со всеми типами, что я проверял, кроме EEM.
У составного и "простого" разные форматы device descriptor для начала.

Я не видел дескриптора EEM "в глаза", и могу только гадать что там должно быть. В даташите от USB.org написано, что эти значения можно применять не только для "Interface Descriptor", но и для "Device Descriptor".
Если 02, 0С, 07 можно поставить прямо в "Device Descriptor", значит возможна и такая конфигурация.
Потому и предложил это рассмотреть.

Но если дело точно не в дескрипторах, тогда я пока ничего больше предложить не могу.

Вот такие тоже не работают...

zzz1.pdf именно такой случай.

Применил тяжелую артиллерию...
На другом процессоре (Renesas RZA1L) на USB HS интерфейсе одиночный CDC EEM нормально опознался!
Однако, соответствующее USB composite device в дереве device manager-а не появилось...
При этом, на USB FS так же с ошибкой о неудачном запуске.
Если добавлялись иные функции, так же нормально работает и на FS и на HS.

ps: в endpoint дескрипторах с типом bulk поле bInterval не игнорируется, а имеет вполне конкретное назначение.

Под линуксом что UAC+ECM, что EEM отдельно опознается нормально. Десятки нет и не будет. Под семеркой - код 28, "нет драйвера".
Пробовал покупную сетевуху на ASIX..178 - она вообще vendor defined class. Драйвер подгрузился автоматом из интернета. Может быть, рабочий дескриптор EEM на симках/смарткартах можно увидеть?