На данный момент в устройствах для обмена с "внешним миром" есть целых три протокола - один для RS-232/485, один для USB, и один для etehrnet. Так уж "исторически" получилось . В итоге появилось осознанное желание оставить только TCP/IP, а "несетевые" интерфейсы перевести на "пакетный режим" - IP. Для RS-232 скорее всего будет SLIP и/или PPP, для RS-485 - пока нет ясности, а вот для шины USB некая компания Microsoft предлагает RNDIS - драйверы в Windows имеются готовые, осталось "уговорить принцессу" написать свой firmware. Поиск по форуму и в Сети ничего толкового не дал, может быть уважаемый All чего полезного посоветует в качестве отправной точки? Платформа без разницы - интересует лишь пример реализации - "just for reference"

RNDIS по сути транспортирует Ethernet пакеты
Нафик устройствам такой оверхед?
Делаете на USB виртуальный COM порт и присоединяетесь по PPP способом Direct Cable Connection. Оверхед будет меньше.

Тоже вариант. Но разницу между фреймами PPP/802.3 не считаю принципиальной, судя по описанию RNDIS от MS - ничего там сильно оверхедного нет. Все равно в устройстве есть полный сетевой стек - осталось только интерфейсы нужные дописать - а это 10-15% от всей уже проделанной работы. Впрочем, PPP будет имплементироваться "по-любому" - для модемов/RS-232, поэтому без проблем можно будет попробовать и на CDC.
Еще виртуальный COM на USB не особо хочется из-за проблем в "штатных" драйверах Windows. Да, в XP SP(какой-то) вроде уже получше с usbser.sys стало, но у нас есть клиенты и на 98SE/2000 (есть и на 95/DOS, но им USB "даже не сниться").
RNDIS же в действии видел - мой КПК по USB так подключается. На мой взгляд - вполне элегантное решение, для пользователя все просто - подключил шнурок и получил сетевое соединение автоматически. Еще недавно был на семинаре Telit - там тоже плату подключали по USB, на плате был Linux c RNDIS-клиентом, и кажется, даже u-boot работал по сетке через USB.

Кстати, я так понимаю, RNDIS сам по себе поднимается, без необходимости пинания руками, в отличии от, скажем, PPP?

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

Сочувствую.
Выж не клиент, а разработчик.
PPP через виртуальный COM также автоматом включается как и RNDIS. Надо только incoming connection в винде поставить на прослушивание.
Эта фишка в виндах по моему с версии 3.11 идет.
Только RNDIS по USB ой как сложно вам будет снифить, не в пример PPP по COM порту.

Спасибо . Только сочувствие не требуется, скорее наоборот - это ж интересно - заимплементить весчь типа RNDIS.

То есть? "Сверху" на PC RNDIS пакеты нормально возьмутся ethereal (aka wireshark) (работает по NDIS), "снизу" на USB - софтовым сниффером типа USBlyser. С этими обоими снифферами уже много работал - особых проблем не вижу. Потенциальная проблема может быть в неполноте спецификации RNDIS от MS - но там драйверы крошечные, и к ним символы в pdb выложены. Собственно имеется некоторый опыт и с самим NDIS (приходилось работать в команде по написанию firewalls), поэтому все "непонятки" можно будет выяснить при помощи IDA. Еще большой плюс RNDIS (по сравнению с текущим используемым WinUSB), что он работает начиная от Win98.

Вижу вы уверены, что сокращения вам еще долго не грозят

Стек USB функции с коммуникационным профилем, профилями Ethernet, NDIS и стандартными MIB-ами занимают 39 тыс. строк исходников.
Судя по вашим метрикам производительности из недавних ваших постов работы вам здесь на многие годы.

Да, а посмотреть можете в Windows Embedded CE 6.0 Platform Builder, там почти весь RNDIS открыт.

Хм, разве в нонешний кризис можно быть в чем-то уверенным? Но плотный такой план работ на год-полтора есть


39K? Немало, но и не очень много . SNMP мне не нужен (или MIB-ы для чего другого?), по USB большой и хороший задел есть, с NDIS-ом работал (правда, сами минипорты не писал, но структуры данных и потоки более-менее знакомы). А про "многие годы" - увы, вполне реально , когда два-три проекта "в параллель" + "текучка" - совсем не смешно.


Спасибо, а то у меня 5-ый установлен, я глянул - ничего особо полезного не увидел - вряд ли я 6-ой специально "на посмотреть" тянул бы.

Так на что собираетесь портировать RNDIS? Процессор? Операционка?
Win CE значит туда не может залезть?
И вам все-таки функцию или хост хочется реализовать?
SNMP вообще-то для отладки очень удобен.
У вас разве нет этапа функционального тестирования сетевых протоколов.
Или сетевой интерфейс в ваших дивайсах просто дань моде и не интегрируется в M2M (machine to machine) системы и не работает дальше локальной сетки?

В-основном - LPC/SAM, без внешней памяти. TNKernel, "доработанный напильником".


Увы, не может. Оно и неплохо было бы платформу взять помощнее + Linux/WinCE - да по деньгам на аппаратуру жмут сильно. Исходим из того что микроконтроллер с флешем и рамой на борту всегда будет стоить дешевле отдельного процессора и отдельных памятей, хотя бы их рабочие параметры и были на порядок выше.


Только функцию. Хочется подключить свое устройство по USB к PC и увидеть его в качестве сетевого соединения. Соответственно внутри устройства вместо нескольких протоколов - TCP/IP + проприетарные на USB/RS-232/485 хочется оставить только TCP. USB-хост, работающий с RNDIS устройствами не нужен и маловероятно что понадобится.
Впрочем, пока ситуация складывается так, что сначала будет делаться таки PPP (модемные соединения у меня вообще пока никак "не прикрыты", в отличие от USB) и я, скорее всего, последую Вашему совету и попробую PPP over USB. Если результат будет неудовлетворительный, то уже буду "выдвигаться" на RNDIS. Спецификацию я сегодня внимательно прочитал - поднимабельно.



Вполне может быть. У меня статистика в сетевом стеке ведется достаточно подробная, я могу ее локально через отладочный канал в любой момент посмотреть. Если понадобится удаленно - всегда можно будет организовать это все в MIB и подцепить SNMP, но пока не понадобилось. Рулить устройствами по сетке тоже особо не надо, даже не поощряется, поэтому SNMP пока побоку.
Насчет тестирования - это полный кабздык - собственно тестирование TCP/IP заняло 80% времени от написания. Я тут на форуме подымал тему автоматизированного тестирования сетевого стека - увы, особого интереса это не вызвало. Пришлось писать тесты "ручками". В итоге - тестовое покрытие оцениваю в 85-90% кода, что несколько тревожит.


Пока TCP/IP только способ использовать интерфейс ethernet и, в-основном, в локальной сетке. Добавится PPP - пойдут и внешние сети.

Я писал. В общем, реализация приема/передачи Ethernet фрэймов (RNDIS/CDC) вместе с поддержкой USB дэвайса занимает примерно 1500 строк.
Идею брал из ядра линукса - там есть поддержка 'USB gadget'. За неделю реально сделать (если есть опыт с USB периферией).
Тема достаточно легкая (на мой взгляд проще, чем PPP).
Советую плюнуть на virtual COM port - и сразу делать RNDIS (тем более, основная сложность - 'TCP/IP' уже есть).
Сниффить Ethereal'ом.

Уважаемый Concorde, прошу Вас ответить на вопрос - для реализации RNDIS/CDC в приборе требуется обработка контрольного эндпойнта (EP0), а также конкретные режимы других эндпойнтов ? Другими словами, необходим ли полноценный контроллер USB или можно обойтись конвертером RS232-USB (на стороне прибора UART) ?

Нет, конвертор не подойдет.
Да, обязательно надо обрабатывать EP0 - сообщения (кроме нагрузки) RNDIS идут через EP0.
Кроме того, нужен один 'BULK' endpoint (данные), и один 'INTERRUPT' endpoint (для нотификации, что пришли данные).

А вы уверены что делали RNDIS и что вы сами его делали?
Endpoint 0 вообще-то нужен всегда и для любых USB дивайсов к RNDIS-у это имеет малое отношение.
А вот конечная точка типа interrupt там не нужна. Не те скорости. Обмен interrupt в USB слишком медленный.
И рабочий канал и контрольный настроены как bulk.
Ну и отладочный интерфейс не забыть через тот же USB.
Вообщем точек 5-6 обрабатывать нужно.

Interrupt EP там точно нужна - устройство по ней оповещает хост о наличии сгенерированного ответа на управляющий пакет - высылается RESPONSE_AVAILABLE и хост далее читает реальный ответ по EP0. Управляющие пакеты "случаются" довольно редко - тут скорость не требуется, а собственно сетевые данные "ходят" по своим отдельным EP типа bulk.

Мне не понятны ваши сомнения.
Писал я, года 3 назад.
Для чего 5-6 точек ?
Отлаживать там нечего (при условии, что остальной код нормально работает).
Естественно, что EP0(bulk) нужен всегда и везде.
Поддержка RNDIS как такого занимает строк 200 крайне простого кода, т.к. делать там особо нечего.
Самое сложное - обеспечить статистику (подсчет байтов/пакетов) - т.к. Винда (по крайней мере, XP) показывает статистику
интерфейса, запрашивая его через RNDIS (а не считает сама).

У меня вопрос конкретно по Remote NDIS.

Ваяю обработку запросов по спецификации Remote NDIS. Чип юзаю от кипариса FX2LP.
По ходу дела столкнулся с таким траблом.
В спецификации изложено, что
1)хост передает в запросе Send Encapsulated Command сообщение
REMOTE_NDIS_INITIALIZE_MSG (Size 24 bytes):
02 00 00 00
18 00 00 00
02 00 00 00
01 00 00 00
00 00 00 00
00 40 00 00
2)девайс подтверждает его получение передачей RESPONSE_AVAILABLE по Endpoint INTERRUPT
3)на что хост, выставив запрос GET_ENCAPSULATED_COMMAND, забирает данные от девайса в сообщении
REMOTE_NDIS_INITIALIZE_CMPLT(Size 52 bytes):
80 00 00 02
00 00 00 34
02 00 00 00
00 00 00 00
00 00 00 01
00 00 00 01
00 00 00 01
00 00 00 00
00 00 00 01
00 00 05 3A
00 00 00 03
00 00 00 00
00 00 00 00

А дальше одни непонятки...

Вопрос №1. После GET_ENCAPSULATED_COMMAND нужно ли передавать RESPONSE_AVAILABLE?
Вопрос №2. Если я отвечаю RESPONSE_AVAILABLE на запрос GET_ENCAPSULATED_COMMAND, то хост снова выставляет запрос GET_ENCAPSULATED_COMMAND. А т.к. данные я уже передал, и передавать нечего, хост на этом прекращает инициализацию. Потом решил ему постоянно передавать REMOTE_NDIS_INITIALIZE_CMPLT. И тут хост как начал метелить GET_ENCAPSULATED_COMMAND в цикле, что я испугался и впал в ступор

Вопрос №3. Что я делаю неправильно?


По документу вроде хост должен вычитать пакет данных из Bulk IN. Но таких запросов что-то не наблюдается... ((

Э-э-э-э, а с порядком байтов у Вас ничего не напутано случайно?


Нет, не нужно. RESPONSE_AVAILABLE следует высылать тогда, когда Вы готовы что-то передать хосту - результат выполнения предыдущих посланных rоманд или какую-либо асинхронную нотификацию. Поскольку RA посылается в interrupt endpoint, то хост увидит это сообщение достаточно быстро и выдаст запрос GET_ENCAPSULATED_COMMAND, на который и следует выдать имеющиеся данные (результат выполнения команды присланной в SEND, например).


Правильно, высылая новый RA Вы говорите хосту что у Вас еще что-то есть, вот он и спрашивает новым GET-ом.


До запуска хостом чтения по Bulk IN еще достаточно далеко - нужно перейти в состояние data-inited, а для этого маска фильтров устанавливается хостом при помощи SEND/RA/GET, поскольку у Вас этот механизм еще не запустился - то до чтения Вы и не дошли пока.

Точно! Здесь и порылась собака. Получается, я отправляю каждый DWORD в прямом порядке, а нужно в обратном.

Объясню на примере.
Короче получается, что значение всех полей по документации
#define REMOTE_NDIS_INITIALIZE_CMPLT 0X80000002
на самом деле нужно переворачивать вот так
#define REMOTE_NDIS_INITIALIZE_CMPLT 0X02000080
и передавать.
Получаю также в перевернутом виде.

Не могу понять почему так?
И нужно ли менять последовательность байт в DWORD в остальных полях???

Пример.
1) Хост передает:
REMOTE_NDIS_INITIALIZE_MSG (Size 24 bytes):
00000000 02 00 00 00 ....
00000004 18 00 00 00 ....
00000008 02 00 00 00 ....
0000000C 01 00 00 00 ....
00000010 00 00 00 00 ....
00000014 00 40 00 00 .@..

2) Хост принимает:
REMOTE_NDIS_INITIALIZE_CMPLT(Size 52 bytes):
а) так не верно
00000000 80 00 00 02 €...
00000004 00 00 00 34 ...4
00000008 02 00 00 00 ....
0000000C 00 00 00 00 ....
00000010 00 00 00 01 ....
00000014 00 00 00 01 ....
00000018 00 00 00 01 ....
0000001C 00 00 00 00 ....
00000020 00 00 00 01 ....
00000024 00 00 05 3A ...:
00000028 00 00 00 03 ....
0000002C 00 00 00 00 ....
00000030 00 00 00 00 ....

б) так операция success
00000000 02 00 00 80 ...€
00000004 00 00 00 34 ...4
00000008 02 00 00 00 ....
0000000C 00 00 00 00 ....
00000010 00 00 00 01 ....
00000014 00 00 00 01 ....
00000018 01 00 00 00 ....
0000001C 00 00 00 00 ....
00000020 00 00 00 01 ....
00000024 00 00 05 3A ...:
00000028 00 00 00 03 ....
0000002C 00 00 00 00 ....
00000030 00 00 00 00 ....

Но как будет верно?


Также хост передал REMOTE_NDIS_QUERY_MSG.
Таким образом дело дошло до сообщения REMOTE_NDIS_HALT_MSG.
И на это всё. На REMOTE_NDIS_HALT_MSG я никак не реагирую и ничего не делаю.

Шина USB работает в формате little-endian, это значит что все многобайтовые поля - 16-ти и 32-х битовые слова передаются начиная с младшего байта.

Нужно передавать как последовательность байт: 02 00 00 80


Не знаю, я с Кипарисом FX2LP не работал, если он little-endian, то - не нужно. В некоторых процессорах еще и выравнивание по адресу для обращения к HWORD/DWORD требуется.


Вероятно у Вас еще где-то ошибки. Я советую Вам взять программный анализатор шины USB - например, USBlyzer версии старше 1.2, и промониторить подключение любого устройства с Windows Mobile 6.0 - КПК или смартфона - они именно по RNDIS подключаются и весь обмен прекрасно видно.

Теперь понятно. Почитаю документацию на компилятор...


Я сейчас как раз и юзаю USBlyzer. Удобная весчица

Спасибо за ответы и советы. Буду ковырять дальше.

Вопрос.
FX2LP настроен на режим Slave FIFO.
Внешний master - FPGA.
В EP8IN приходит первый пакет данных.
Перед передачей его хосту необходимо в начало пакета добавить заголовок.
Затем в хост передать заголовок+данные.
Как реализовать такой алгоритм в режиме ручного управления fifo?
Или лучше данный заголовок формировать в FPGA и передавать хосту в автоматическом режиме?

Добрый день!
Сейчас занимаюсь такой-же задачей RNDIS на Cypress FX2. Остановился на отправке REMOTE_NDIS_INITIALIZE_CMPLT.
Получаю REMOTE_NDIS_INITIALIZE_MSG
Высылаю RESPONSE_AVAILABLE через INTERRUPT EP
Получаю GET_ENCAPSULATED_RESPONSE
Отвечаю REMOTE_NDIS_INITIALIZE_CMPLT (не уверен что код отправки правильный)
На этом всё...

DiMonstr,
Можно-ли увидеть код под FX2 для отправки REMOTE_NDIS_INITIALIZE_CMPLT?
Помогите, ато застрял...

Добрый день!
С REMOTE_NDIS_INITIALIZE_CMPLT вроде разобрался. Теперь возник вопрос с отправкой OID_GEN_SUPPORTED_LIST. Размер пакета получается больше EP0BUF. Как правильно разделить пакет или как заставить работать Setup Data Pointer для этого случая ?