Есть желание сделать TCP/IP over USB, Порекомендуйте стартовую точку для реализации RNDIS Опции

[VslavX]

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

[DiMonstr]

У меня вопрос конкретно по 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

[VslavX]

REMOTE_NDIS_INITIALIZE_MSG (Size 24 bytes):
02 00 00 00
...
REMOTE_NDIS_INITIALIZE_CMPLT(Size 52 bytes):
80 00 00 02
...

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

Вопрос №1. После GET_ENCAPSULATED_COMMAND нужно ли передавать RESPONSE_AVAILABLE?

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

Вопрос №2. Если я отвечаю RESPONSE_AVAILABLE на запрос GET_ENCAPSULATED_COMMAND, то хост снова выставляет запрос

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

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

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

[DiMonstr]

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

Точно! Здесь и порылась собака. Получается, я отправляю каждый 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 я никак не реагирую и ничего не делаю.

[VslavX]

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

#define REMOTE_NDIS_INITIALIZE_CMPLT 0X80000002

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

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

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

И нужно ли менять последовательность байт в DWORD в остальных Таким образом дело дошло до сообщения REMOTE_NDIS_HALT_MSG.

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

[DiMonstr]

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

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

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

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

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