Как повысить скорость прокачки данных через 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, получал ожидаемые большие скорости обмена данными и знает где нужно изменить код.

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

[Kail]

Альтернатив нету. По книжке Агурова - втроенный драйвер поддреживает только до 64 Кбит/сек или около того. Чего хватает для мыши, клавы и проч устройств. Нужен full-speed - придется писать дройвер с помощью DDK.

[OlegHmt]

Альтернатив нету. По книжке Агурова - втроенный драйвер поддреживает только до 64 Кбит/сек или около того. Чего хватает для мыши, клавы и проч устройств. Нужен full-speed - придется писать дройвер с помощью DDK.

Не уверен. У Агурова насколько я помню ограничение в 64к дано только для HID устройств, а это CDC. Да и скорость у меня уже 125 кбит. Похоже что проблема не тут.
Может много времени занимает копирование данных из FIFO USB в приёмную очередь?

[ivstech]

Какой драйвер используете? Я - стандартный из Windows. И я думал, что 64К - это "потолок" для CDC. Интервал опроса 1мс, размер данных для конечной точки 64байта. Или при энумерации утстройства нужно передавать в дескрипторах другое значение, а не 64? Я переделываю пример атмела BASIC_USB. Кстати, по книге Агурова если размер передаваемых данных совпадает с объемом буфера конечной точки, то нужно передать еще 0 байтов. В примере Атмела так не делают, а я в конечную точку 0 пытался передать 8 байтов (описываемая ситуация) - название устройства.... и ничего не работало.

Так, про драйвер зря спросил....
А может, это винда тормозит?
Я сталкивался с тем, что если написать в процессе опроса
Application->ProcessMessages....
то нужно вставить хотя бы delay(1), иначе ReadFile(hComm....) не отработает. К чему бы это?

[OlegHmt]

Какой драйвер используете? Я - стандартный из Windows. И я думал, что 64К - это "потолок" для CDC. Интервал опроса 1мс, размер данных для конечной точки 64байта. Или при энумерации утстройства нужно передавать в дескрипторах другое значение, а не 64? Я переделываю пример атмела BASIC_USB. Кстати, по книге Агурова если размер передаваемых данных совпадает с объемом буфера конечной точки, то нужно передать еще 0 байтов. В примере Атмела так не делают, а я в конечную точку 0 пытался передать 8 байтов (описываемая ситуация) - название устройства.... и ничего не работало.

Так, про драйвер зря спросил....
А может, это винда тормозит?
Я сталкивался с тем, что если написать в процессе опроса
Application->ProcessMessages....
то нужно вставить хотя бы delay(1), иначе ReadFile(hComm....) не отработает. К чему бы это?

На задержку винды не похоже, так как посылаю один масив в 249 байт и он приходит в моё устройство пакетами в кадрах номера которых разняться на единицу, двойку. А при таком разбросе как раз и получается где-то 125кбит/с данных.
Что-же касается CDC, то там, как мне кажется, скорость не ограничена - сколько можна выжать столько и выжмется.
Ещё добавлю, что у меня две конечные точки одна на вход, другая на выход (плюс нулевая), данные кидаются в bulk пакетах. Кроме этих данных других типов передачи не добавляется.

[gormih]

Это мне тоже очень инетерсно.

Поговорил с человеком на эту тему. Сказал, что когда работал с блютуз - у него тоже возникли проблемы с виртуальным портом на той же скорости - больше не давало, чем 115200. Думаю, что проблема все таки в драйвере винды, и нужно писать свой. Или же искать готовый, чем намерен заняться в ближайшее время. Если не найдем - будем писать все вместе :-)

[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 кб/с.

[gormih]

Неправильный у Вас наверное USB был.

Веселое обоснование.

Изделие как правило должно обладать таким свойством, как повторяемость. Если мы вот так будем писать правельное-неправлеьное - грошь цена таким высказываниям. Другие устройства, такие как flash drive например спокойно работают на этом же порте с довольно высокой скоростью, а вот виртуальный com порт не хочет. В этом вопрос, и вопрос принципиальный.

[Alechek]

Другие устройства, такие как flash drive например спокойно работают на этом же порте с довольно высокой скоростью, а вот виртуальный com порт не хочет. В этом вопрос, и вопрос принципиальный.

Правильно. Это значит что теоретически USB может дать скорость 10-12 мбит через одну логическую точку (как ее использует Mass Storage).
А вот реализация конкретного драйвера - здесь можно многое потерять. Недаром у многих возникают проблемы с CDC мелкософтовским. Значит надо уточнять версию драйвера. Ведь известно, что в Win2k он сильно глюкавый. И его надо менять на такой же от WinXP.
И камень. Я работаю с LPC124х. Устройство реально СЧИТЫВАЕТСЯ на 100 кб/с.
OlegHmt пытается в AT91 ЗАПИСАТЬ на скорости 5 мбит.
Направление у нас разное. Может на передачу CDC ограничен.

[Dron_Gus]

Я думаю, SAM7S и SAM7X в плане USB идентичны. Мне, при экспериментах с первым, удавалось получить 32 Кбайта/сек со своим драйвером. Посылки по 64 байта. При использовании примера Mass Storage от Atmel 1 Мб за 25 сек. Это еще шустрее.

[OlegHmt]

Вчера немного разбирался с проблемой и вот что смог найти, вычитал на форуме, но не успел попробовать. Тут же на форуме раньше поднималась похожая тема, но люди использовали CDC на базе BasicUSB от Atmela. В качестве драйвера виртуального ком-порта использовался всё тот-же usbser.sys, правда работали они с ним с использованием usblibrary.dll (код тоже идёт в комплекте), где открывание порта и передача даных организована немного по другому. И там народ получал скорости вплоть до установленого пределе 1 Мбайт/с. Сегодня вечерком попробую разобраться с такой последовательностью работы с портом и запустить.
То-есть пока два варианта тормозов при передаче данных:
1. неправильно организована работа процесора в моём устройстве;
2. некоректно работают функции передачи данных на ПК.
Второй вариант сегодня попробую проверить

[gormih]

а мне посоветовали "забить" на виртуальный com порт, и пользовать USBIO.

Как только придет горячо ожидаемая плата - сразу займусь экспериментами.

[OlegHmt]

а мне посоветовали "забить" на виртуальный com порт, и пользовать USBIO.

Как только придет горячо ожидаемая плата - сразу займусь экспериментами.

Если можно, то поподробнее о USBIO - с чем его едят и от чего отталкиваются? И почему всё же "забить" - по какой причине?

[gormih]

Если можно, то поподробнее о USBIO - с чем его едят и от чего отталкиваются? И почему всё же "забить" - по какой причине?

Наверное по той самой причине, что виртуальный com порт в том виде в каком он описывается в данном применении в принципе не может обеспечить высокой скорости обмена. Однако на сколько мне известно, чипы FTDI например поддерживаются драйвером с виртуальным com портом со скоростью до 1 Мбит.



Относительно USBIO 20 - это библиотека, кому надо могу дать ссылку или попросить отправить на mail. Там куча экземплов, и на сколько видно из описания поддерживает вплоть до USB 2.0.