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

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

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

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

Я тестировал скорость передачи данных от компа на девайс по full-speed USB и получил 500КБайт/сек. В качестве контроллера использовался SiLabs C8051F347. Включал двойную буферизацию на прием, размер буфера 256 байт. Мне хватило. При этом я думаю скорость передачи тормозилась только скоростью забора данных микроконтроллером.
Кстати был обнаружен интересная ошибка в драйвере usbser.sys от небезызвестного производителя. IN endpoint буфер был сконфигурирован 256 байтного размера. При передаче всех 256 байтов данных в компьютер гарантированно получался "'экран смерти" . Ошибку обошел простым увеличением размера буфера до 257 байт (естественно в дескрипторе) .
На данный момент устройство успешно реализовано и выглядит как виртуальный COM-порт.

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

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

В вашем случае вероятнее виновата выбранная схема взаимодействия задач с USB периферией.
Вы измеряли время переключения задач?
А ситуации заполненной очереди отслеживали?
А сколько во FreeRTOS длится сама постановка в очередь?
На таких скоростях это уже все критично.
Выборка из FIFO думаю должна производиться в самом обработчике прерывания и как можно быстрее еще лучше использовать DMA для этой цели.
Я тоже пишу под RTOS и там имеено эти моменты дают самые большие тормоза.

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

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

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

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

[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, данные в основном идут в устройство, обратно - подтверждения. Пока эта скорость устраивает.

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

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

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

Сейчас попутно поставил эксперименты.
со чтороны девайса LPC2148, тупое чтение данных из точки в никуда.
со стороны хоста USB 1.1 Celeron 1800, Чтение данных из файла и посыл их в порт.
максимально достигнутое - ~900 000 байт/сек
доступ к порту средствами WinApi, открытие порта по символьному имени (не COMx)
как я понял, в течении кадра передается не больше того, что было послано WriteFile.
Чем больше размер записи - тем быстрее скорость. Прямой зависимости нет
512байт - ~ 250 000 байт/сек
1024 - ~ 410 000
2048 - ~520 000
4096 - ~ 750 000
8192 - ~ 830 000
16384 - ~ 900 000

ЗЫ Были грабли что от всей посылки приходит только первые 64 байт. Вроде вылечилось
установкой SetupComm(PortHandle, 16384, 16384) на хосте

Скажите специалисты. А если требуется реализация полного виртуала со всеми линиями. DTR, DSR, RI, RTS, CTS ну и так далее. Кто-нибудь такое делал?

Такое точно делал MosChip . У них есть такая микруха USB-UART MCS7840 - это USB2.0 HighSpeed и 4 виртуальных ком порта (с DTR, DSR, RI, RTS, CTS ну и так далее ). Обещают до 6Мбит. Пока только заказываю, попробую в деле. Дрова есть под все ОСи ссылка

Наконец дошли у меня руки до исследований USB и вот каков результат: как и писал AlexandrY проблема оказалась в постановке принятых данных в очередь. Как только я заменил постановку в очередь на запись в обычный масив - тут же скорость подскочила: за одну милисекунду (один фрейм) у меня приходило от ПК 7-11 пакетов данных (по 64 байта). То-есть я получал где-то 600 кБайт на секунду. Скорость ещё бы можно поднять изменив процедуру выборки даных из FIFO, но это уже следующий этап - полностью переработать алгоритм работы с посылками USB. Надеюсь больше не вылезут какие-то косяки, особенно с передачей данных от устройства к ПК - пока-что я этой части особо не исследовал.

Кстати, может кому-то пригодится и такая информация. Когда я пробовал сделать на Delphi работу с виртуальным последовательным портом аналогично процедуре в примере BasicUSB, то получил таков результат: Я смог перенести часть кода которая получает список устройств и их описание, но когда пробовал открыть два канала с портом (аналогично BasicUSB), то открывался только тот, который в коде шёл первым. Второй никак не хотел открываться пока не закроется первый.
И ещё одно - данные в открытый канал записывались, но не доходили до устройства. Если же перед открытием канала я открывал порт старым способом: handle:=CreateFile('\\.\COMX', ..... ) после чего устанавливал и читал установленную скорость и сразу же закрывал порт CloseHandle(handle), то после этого в открытый канал по способу BasicUSB данные нормально записывались и доходили до устройства.

И напоследок - большое спасибо всем кто откликнулся, так или иначе вся информация топика оказалась полезной

Интересно было бы узнать, чем всё закончилось? Какую скорость получили?