Мне не понятны ваши сомнения.
Писал я, года 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. Но таких запросов что-то не наблюдается... ((

Сообщение отредактировал DiMonstr - Feb 6 2010, 18:49

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


Нет, не нужно. 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 для этого случая ?