Как повысить скорость прокачки данных через 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. Они его сейчас вылизали. Работает как часы.

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