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

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

[klen]

Мдя.
Используя lpc2148 c открытым USB стеком и как mass storage и как custom устройство дает 0,33 мегабайта в секунду при обмене буффер прилагухи или файл диска <--> записи/считывании в озу контроллера. контроллер работает на 60 мегагерцах.
Гденить порытся в исходниках и откопать еще скорость возможно (исходники USB стека для 2148 и драйвера на PC ессесено доступны)? Куда рылом похать.
Начальник сказал что такая скорость пойдет для текущего проекта. Что меня не мало успокоило.
Эта скорость как? медленно, быстро? или так себе? Некоторые тут аж 600кбайт/сек какимто волшебным способом получили .... У кого больше скорость обмена получилось? и при каких остоятельствах вы ее видели в последний раз?