Jump to content

    

Есть желание сделать TCP/IP over USB

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

Share this post


Link to post
Share on other sites

RNDIS по сути транспортирует Ethernet пакеты

Нафик устройствам такой оверхед?

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

 

 

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

Сочувствую.

Выж не клиент, а разработчик.

PPP через виртуальный COM также автоматом включается как и RNDIS. Надо только incoming connection в винде поставить на прослушивание.

Эта фишка в виндах по моему с версии 3.11 идет.

Только RNDIS по USB ой как сложно вам будет снифить, не в пример PPP по COM порту.

 

 

RNDIS же в действии видел - мой КПК по USB так подключается. На мой взгляд - вполне элегантное решение, для пользователя все просто - подключил шнурок и получил сетевое соединение автоматически. Еще недавно был на семинаре Telit - там тоже плату подключали по USB, на плате был Linux c RNDIS-клиентом, и кажется, даже u-boot работал по сетке через USB.

Share this post


Link to post
Share on other sites
Сочувствую.

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

Только RNDIS по USB ой как сложно вам будет снифить, не в пример PPP по COM порту.

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

Share this post


Link to post
Share on other sites

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

 

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

Судя по вашим метрикам производительности из недавних ваших постов работы вам здесь на многие годы. :biggrin:

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
Вижу вы уверены, что сокращения вам еще долго не грозят ;)

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

 

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

Судя по вашим метрикам производительности из недавних ваших постов работы вам здесь на многие годы. :biggrin:

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

 

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

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

Share this post


Link to post
Share on other sites

Так на что собираетесь портировать RNDIS? Процессор? Операционка?

Win CE значит туда не может залезть?

И вам все-таки функцию или хост хочется реализовать?

SNMP вообще-то для отладки очень удобен.

У вас разве нет этапа функционального тестирования сетевых протоколов.

Или сетевой интерфейс в ваших дивайсах просто дань моде и не интегрируется в M2M (machine to machine) системы и не работает дальше локальной сетки?

 

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

Share this post


Link to post
Share on other sites
Так на что собираетесь портировать RNDIS? Процессор? Операционка?

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

 

Win CE значит туда не может залезть?

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

 

И вам все-таки функцию или хост хочется реализовать?

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

Впрочем, пока ситуация складывается так, что сначала будет делаться таки PPP (модемные соединения у меня вообще пока никак "не прикрыты", в отличие от USB) и я, скорее всего, последую Вашему совету и попробую PPP over USB. Если результат будет неудовлетворительный, то уже буду "выдвигаться" на RNDIS. Спецификацию я сегодня внимательно прочитал - поднимабельно.

 

SNMP вообще-то для отладки очень удобен.

У вас разве нет этапа функционального тестирования сетевых протоколов.

 

Вполне может быть. У меня статистика в сетевом стеке ведется достаточно подробная, я могу ее локально через отладочный канал в любой момент посмотреть. Если понадобится удаленно - всегда можно будет организовать это все в MIB и подцепить SNMP, но пока не понадобилось. Рулить устройствами по сетке тоже особо не надо, даже не поощряется, поэтому SNMP пока побоку.

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

 

Или сетевой интерфейс в ваших дивайсах просто дань моде и не интегрируется в M2M (machine to machine) системы и не работает дальше локальной сетки?

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

Share this post


Link to post
Share on other sites

Я писал. В общем, реализация приема/передачи Ethernet фрэймов (RNDIS/CDC) вместе с поддержкой USB дэвайса занимает примерно 1500 строк.

Идею брал из ядра линукса - там есть поддержка 'USB gadget'. За неделю реально сделать (если есть опыт с USB периферией).

Тема достаточно легкая (на мой взгляд проще, чем PPP).

Советую плюнуть на virtual COM port - и сразу делать RNDIS (тем более, основная сложность - 'TCP/IP' уже есть).

Сниффить Ethereal'ом.

Share this post


Link to post
Share on other sites

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

Share this post


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

Нет, конвертор не подойдет.

Да, обязательно надо обрабатывать EP0 - сообщения (кроме нагрузки) RNDIS идут через EP0.

Кроме того, нужен один 'BULK' endpoint (данные), и один 'INTERRUPT' endpoint (для нотификации, что пришли данные).

Share this post


Link to post
Share on other sites

А вы уверены что делали RNDIS и что вы сами его делали? ;)

Endpoint 0 вообще-то нужен всегда и для любых USB дивайсов к RNDIS-у это имеет малое отношение.

А вот конечная точка типа interrupt там не нужна. Не те скорости. Обмен interrupt в USB слишком медленный.

И рабочий канал и контрольный настроены как bulk.

Ну и отладочный интерфейс не забыть через тот же USB.

Вообщем точек 5-6 обрабатывать нужно.

 

Нет, конвертор не подойдет.

Да, обязательно надо обрабатывать EP0 - сообщения (кроме нагрузки) RNDIS идут через EP0.

Кроме того, нужен один 'BULK' endpoint (данные), и один 'INTERRUPT' endpoint (для нотификации, что пришли данные).

Share this post


Link to post
Share on other sites
А вот конечная точка типа interrupt там не нужна. Не те скорости. Обмен interrupt в USB слишком медленный.

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this