Как повысить скорость прокачки данных через virtual COM (USB), CDC из пакета FreeRTOS для AT91SAM7X256 Опции

[OlegHmt]

Нужно организовать обмен данными между ПК и камнем. В основном данные записываются в камень, но небольшие пакеты подтверждения состояния процеса в камне передаются в ПК.
В качестве базового кода использовал пример lwIP_Demo_Rowley_ARM7 из пакета FreeRTOS выбросив оттуда работу с сетью и добавив ещё одну задачу обработки данных от USB. В результате, у меня в системе крутятся две задачи: первая (с высшим приоритетом) производит обмен данными между контролером USB и двумя очередями (одна на приём, другая на передачу), вторая - обрабатывает данные используя их для выполнения своих задач. В качестве драйвера устройства используется стандартный виндосовский usbser.sys (работаю под WinXPPro).
В камне зарезервированы очереди на приём (размером 300 байт) и на передачу (размером 100 байт), а также очередь обмена сообщениями между обработчиком прерываний и первой задачей. Насколько я разобрался с протоколом работы USB, в даном примере код написан достаточно грамотно с использованием двойной буферизации (ping-pong процесора) и там не должно бы быть задержек (возможно я не прав). В нескольких словах как это всё работает. По приходе пакета от ПК вызывается прерывание которое записывает информацию о пакете в очередь обмена с задачей и вызывает переключение задач. Первая задача ожидает этого переключения, вытягивает данные из буфера FIFO, запихивает их в очередь приёма, данные из очереди передачи передаёт в FIFO и выставляет нужные флаги. Когда есть время вторая задача обрабатывает данные в очередях.
Запустив всю эту систему я смог получить скорость обмена даными приблизительно 125 кБит/с, а нужно где-то 5Мбит/с.
Чтобы проверить где может быть узкое место я изменил код следующим образом:
в первой задаче, дополнительно при передаче данных из буфера FIFO в очередь приёма я дописывал размер полученого пакета и номер кадра в котором пришёл пакет. Вторая задача все данные из очереди приёма после некоторой задержки отправляла обратно на ПК.
На ПК я отправлял данные из масива размером 249 байт. Програма написана на Delphi. Порт открываю командой hCom:=Createfile(port, GENERIC_READ+GENERIC_WRITE, 0, nil, OPEN_EXISTING, 0, 0);. Скорость обмена устанавливается на камне 115200, но как мне раньше ответили эта скорость, только для совместимости и реально она не ограничивает потока данных (я это проверял - скорость обмена не изменялась при установке других чисел). Данные из программы на ПК я отправлял командой WriteFile(hCom, test[0], 249, bytes, OvLapp);. Как и предполагается в протоколе USB у меня пришло четыре пакета: 64+64+64+57=249. Но почему-то все пакеты приходят не в одном кадре (или в двух соседних кадрах), а через один-два кадра (номера кадров разнятся на две-три единицы). Может я ещё не до конца разобрался со стандартом USB, но вроде-бы, все пакеты могут передаться в одном кадре несколькими транзакциями.
Такое ощущение, что передачу данных тормозит драйвер CDC usbser.sys. Если да, то какая может быть альтернатива? Желательно бы обойтись без написания собственного драйвера.

Возможно кто-то подскажет как можно ещё попробовать поискать где узкое место.
Может кто-то работал с этой реализацией CDC, получал ожидаемые большие скорости обмена данными и знает где нужно изменить код.

Помогите, пожалуйста.

[AlexandrY]

А чем вы смотрите обмен по USB?
Смотреть надо аппаратным анализатором. Он показавает наличе запросов от хоста. Программные логеры этого не видят.

Так вот когда я смотрел работу конечной точки виртуального COM, то наблюдал передачу запросов каждые 5 мкс. Но после того как в кадре проходил один ответ больше запросов от хоста на данную конечную точку до конца кадра не поступало. Следовательно потолок для виртуального COM порта это 64 байта в 1 мс на USB 2.0 FS т.е. 512 КБит/сек

Но почему-то все пакеты приходят не в одном кадре (или в двух соседних кадрах), а через один-два кадра (номера кадров разнятся на две-три единицы). Может я ещё не до конца разобрался со стандартом USB, но вроде-бы, все пакеты могут передаться в одном кадре несколькими транзакциями.

[Alechek]

Но почему-то все пакеты приходят не в одном кадре (или в двух соседних кадрах), а через один-два кадра (номера кадров разнятся на две-три единицы). Может я ещё не до конца разобрался со стандартом USB, но вроде-бы, все пакеты могут передаться в одном кадре несколькими транзакциями.

Все верно. Явно в стандарте не нашел, но по жизни так и есть.

Так вот когда я смотрел работу конечной точки виртуального COM, то наблюдал передачу запросов каждые 5 мкс. Но после того как в кадре проходил один ответ больше запросов от хоста на данную конечную точку до конца кадра не поступало. Следовательно потолок для виртуального COM порта это 64 байта в 1 мс на USB 2.0 FS т.е. 512 КБит/сек

Неправильный у Вас наверное USB был. Я тоже думал что ограничение 64 кбит. Но когда получил максимальную реальную скрорость > 300 кб/с я изменил свое мнение.
При тупой непрерывной посылке байтов контроллером и тупым приемом потока компом (Сел1.7) скорость была что-то около 340-380 кб/с.

[AlexandrY]

Да, вы оказались правы
Что-то тогда было не то.
Сейчас протестировал работу стандартного драйвера виртуальномого COM-а с другого чипа.
Перекачка в окно терминала проходит со скоростью 200 кбайт/сек. Не так все и плохо.
Анализатором еще не смотрел ситуацию на шине, как погляжу может сообщу.

Неправильный у Вас наверное USB был. Я тоже думал что ограничение 64 кбит. Но когда получил максимальную реальную скрорость > 300 кб/с я изменил свое мнение.
При тупой непрерывной посылке байтов контроллером и тупым приемом потока компом (Сел1.7) скорость была что-то около 340-380 кб/с.

[AlexandrY]

Так, новые данные о работе виртуального COM порта.
Скорость считывания из устройства в комп реально ничем не ограничена кроме пропускной способности USB шины и собственно устройства.
Я реально достиг передачи 11-и 64-х битных пакетов за один кадр, т.е. 704 Кбайта в секунду.
И эта граница целиком определялась быстродействием моего устройства (платформа на базе STR91x).
Больше устройство просто не успевало обрабатывать транзакции типа IN.

А вот с передачей данных из компа в устройство сложнее. Комп никак не захотел отдавать более 2-х пакетов за кадр. Причем они шли так: 64 байта, а потом 36 байт. Если комп получал после первого пакета ответ NAK, то он долбил в течении кадра пока не пересылал оба пакета, а потом замолкал до следующего кадра, т.е. переставал отправлять запросы OUT
Перетыкание на другие разъемы USB в компе ситуацию не меняет.
Использовал для посылки данных терминальную программу TeraTerm. Посылал двоичный файл в 1 Мег.
Т.е. пока вывод, что на передачу в устройство достичь скорости более 100 Кбайт в секунду на виртуальном COM порте не удалось.

Да, вы оказались правы
Что-то тогда было не то.
Сейчас протестировал работу стандартного драйвера виртуальномого COM-а с другого чипа.
Перекачка в окно терминала проходит со скоростью 200 кбайт/сек. Не так все и плохо.
Анализатором еще не смотрел ситуацию на шине, как погляжу может сообщу.

Неправильный у Вас наверное USB был. Я тоже думал что ограничение 64 кбит. Но когда получил максимальную реальную скрорость > 300 кб/с я изменил свое мнение.
При тупой непрерывной посылке байтов контроллером и тупым приемом потока компом (Сел1.7) скорость была что-то около 340-380 кб/с.

[Alechek]

Т.е. пока вывод, что на передачу в устройство достичь скорости более 100 Кбайт в секунду на виртуальном COM порте не удалось.

Да, как оказалось, usbser.sys заточен лишь под модем, как и usbprint.sys - чисто под принтер.
Налицо ситуация, когда мелкософтовцы отлаживали лишь приемную часть драйвера...

[AlexandrY]

Ситуация, прояснилась окончательно.
Выводы о кривизне usbser.sys были явно преждевременны.
Похоже тормоза исходят от более верхних прикладных уровней.
На этот раз я для тестирования написал в Delphi свою прогу на базе компонента AsyncPro для работы с виртуальным COM портом.
И сразу скорость закачки в устройство подскочила до максимальной с какой способен принимать мой дивайс, где-то более 200 Кбайт в секунду.

Вообщем HyperTerminal под Windows вообще посылает пакеты чуть не по одному байту. TeraTerm ограничивае трафик в 100 КБ/сек, а вот собственное приложение ничем трафик не ограничивает, но видимо тщательнее надо подходить к инициализации буферов и настройке DCB структуры COM порта. Компонент AsyncPro скрывает от юзера работу с Win API поэтому конкретнее о настройках ничего сказать не могу.

Т.е. пока вывод, что на передачу в устройство достичь скорости более 100 Кбайт в секунду на виртуальном COM порте не удалось.

Да, как оказалось, usbser.sys заточен лишь под модем, как и usbprint.sys - чисто под принтер.
Налицо ситуация, когда мелкософтовцы отлаживали лишь приемную часть драйвера...

[SasaVitebsk]

Ситуация, прояснилась окончательно.
Выводы о кривизне usbser.sys были явно преждевременны.
Похоже тормоза исходят от более верхних прикладных уровней.
На этот раз я для тестирования написал в Delphi свою прогу на базе компонента AsyncPro для работы с виртуальным COM портом.
И сразу скорость закачки в устройство подскочила до максимальной с какой способен принимать мой дивайс, где-то более 200 Кбайт в секунду.

Вообщем HyperTerminal под Windows вообще посылает пакеты чуть не по одному байту. TeraTerm ограничивае трафик в 100 КБ/сек, а вот собственное приложение ничем трафик не ограничивает, но видимо тщательнее надо подходить к инициализации буферов и настройке DCB структуры COM порта. Компонент AsyncPro скрывает от юзера работу с Win API поэтому конкретнее о настройках ничего сказать не могу.

Я делал модем в своё время и тестировал HyperTerminal. Могу сообщить следующее.

1) Из под XP он действительно дробит пакеты и вставляет задержки даже м/у символами. Работает крайне медленно. Это наблюдается на FTDI. На Win98 такого не замечалось.
2) Терминал имеет ошибки при передаче данных. В том числе в режиме X-modem да и других тоже. Более того одну из ошибок мы задиагностировали в 1999 году ещё в Win98. В том году мы её успешно проверили из под WinXP. Всё нормально! В наличии!

Очень интересны Ваши эксперименты, но вот в каком ключе. Мне самому жутко не хочется писать драйвер. Его же потом поддерживать! Хотелось бы со стороны своего девайса с эмулировать наличие там FT232RL. Так, чтобы благополучно подходил драйвер от FTDI. Они его сейчас вылизали. Работает как часы.

Ни кто не думал над этим?

[ivstech]

[quote name='SasaVitebsk' date='Feb 25 2007, 00:47' post='215539']
[quote name='AlexandrY' post='215435' date='Feb 24 2007, 16:23']

Хотелось бы со стороны своего девайса с эмулировать наличие там FT232RL. Так, чтобы благополучно подходил драйвер от FTDI. Они его сейчас вылизали. Работает как часы.

Ни кто не думал над этим?
[/quote]

Вы прямо читаете мои мысли. На настоящий момент мое достижение ~80КБайт/сек. в WinXP с usbser.sys, данные в основном идут в устройство, обратно - подтверждения. Пока эта скорость устраивает.

[SasaVitebsk]

Хотелось бы со стороны своего девайса с эмулировать наличие там FT232RL. Так, чтобы благополучно подходил драйвер от FTDI. Они его сейчас вылизали. Работает как часы.

Ни кто не думал над этим?

Вы прямо читаете мои мысли. На настоящий момент мое достижение ~80КБайт/сек. в WinXP с usbser.sys, данные в основном идут в устройство, обратно - подтверждения. Пока эта скорость устраивает.

Меня вообще за глаза.

А на каком проце вы делали? Чем "подсматривали"? Сложно ли реализовать оказалось?

[ivstech]

Меня вообще за глаза.

А на каком проце вы делали? Чем "подсматривали"? Сложно ли реализовать оказалось?

Я наверное, неправильно выразился. Была у меня мысль использовать драйвер от FTDI. Был у меня фирменный диск с FTDI, и там была таблица с описанием, какая информация берется из EEPROM, подключаемой к FT*** и по-моему, была там и таблица с дескрипторами, копию диска себе не делал.
Но пока я остановился на стандартном usbser.sys и получается 80КБайт/сек.
Процессор AT91SAM7S256. Переделываю BasicUSB по-маленьку. Сделал обработку по прерываниям (не уверен, правда, что это добавляет скорости). Ошибку исправил, я уже где-то об этом писал, может в этом топике, что не учитывают, когда длина блока передаваемых данных равна размеру конечной точки, надо передать еще пакет нулевой длины (информацию эту подчерпнул из книги Агурова). А вообще этот модуль с USB еще переделывать долго буду