Адаптер USB to Ethernet Опции

[DiMonstr]

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

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

[VslavX]

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

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

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

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

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

[DiMonstr]

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

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

[chan]

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

[VslavX]

Значит драйвер для CDC также реализует поддержку EEM протокола.
Кто-нибудь проверял это?

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

[DiMonstr]

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

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

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

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

[Itch]

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

[VslavX]

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

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

[Genadi Zawidowsk...]

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

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

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

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

Эскизы прикрепленных изображений

 

Прикрепленные файлы

 usblyzer_output.pdf ( 398.06 килобайт ) Кол-во скачиваний: 47

 

[Genadi Zawidowsk...]

Есть проблема...
В составном устройстве (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

Прикрепленные файлы

 descriptor.pdf ( 321.55 килобайт ) Кол-во скачиваний: 27

 

[Genadi Zawidowsk...]

err

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

[controller_m30]

Вот дамп дескрипторов.

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

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

[Genadi Zawidowsk...]

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

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

Прикрепленные файлы

 usbd_desc.zip ( 12.53 килобайт ) Кол-во скачиваний: 19

 

[Genadi Zawidowsk...]

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

[controller_m30]

Я нашёл два отличия в дампах для комбинированного устройства, и для единственного.
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

[Genadi Zawidowsk...]

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

...

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

Прикрепленные файлы

 EEM.pdf ( 316.8 килобайт ) Кол-во скачиваний: 32
 2xCDC_ACM_1xCDC_EEM.pdf ( 396.18 килобайт ) Кол-во скачиваний: 29
 eem_ecm.pdf ( 361.76 килобайт ) Кол-во скачиваний: 25

 

[controller_m30]

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

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

[Genadi Zawidowsk...]

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

[controller_m30]

Попробуйте в "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", который вроде бы и не влияет, но вдруг.

[Genadi Zawidowsk...]

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

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

[controller_m30]

EEM работает на дескрипторах EEM. Не ECM.

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

дескриптор EEM сильно от ECM отличается - в ECM два интерфейса, например вместо одного у EEM.

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

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

[Genadi Zawidowsk...]

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

может быть для единственного EEM нужен простой Class

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

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

Прикрепленные файлы

 iadclasscode_r10.pdf ( 51.22 килобайт ) Кол-во скачиваний: 62

 

[controller_m30]

А почему он не нужен для единственного компорта (было), аудиоустройства, 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

[Genadi Zawidowsk...]

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

Последнее посещение: 11th November 2016 - 22:37

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

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


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

Эскизы прикрепленных изображений

 

[controller_m30]

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

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

[Genadi Zawidowsk...]

Но вы же делаете из составного устройства простое, в случае с единственным EEM

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

[controller_m30]

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

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

Эскизы прикрепленных изображений

 

[Genadi Zawidowsk...]

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

Если 02, 0С, 07 можно поставить прямо в "Device Descriptor", значит возможна и такая конфигурация

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

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

Прикрепленные файлы

 zzz.pdf ( 316.48 килобайт ) Кол-во скачиваний: 19
 zzz1.pdf ( 316.5 килобайт ) Кол-во скачиваний: 19

 

[Genadi Zawidowsk...]

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

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

Сообщение отредактировал Genadi Zawidowski - Jan 11 2017, 01:39

Прикрепленные файлы

 USB_CDC_EEM_HS_working.pdf ( 320.28 килобайт ) Кол-во скачиваний: 33

 

[romanetz]

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