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