МикросхемаFT232R (а новый вариант FT2232D) - сейчас очень часто используется для построения моcтов типа USB -> com, USB -> RS485, USB -> JTAG.
У нас возникла проблема с таким переходником USB -> RS485 - медленно работает. С FTDI микросхемой (FT232R) поставляется ихний стандартный драйвер USB-BULK.
Всё замечательно но: отправляем пакет в USB (через их драйвер, через API, которое они дают) с периодичностью 1 раз в миллисекунду (64 байта), а на выходе 485 -ой фиксируем этот пакет в среднем 1 раз в 15 миллисекунд. Как раскачигарить этот драйвер? (Есть апп-нота, что якобы можно поднять приоритет драйвера - пробовали - не помогает). Или это проблема винды и она больше не даст? Может быть вместо WinXP поставить WinXP - Embedded? Это может чем-нибудь помочь? Зрительно на экране видим, что пакет (на XP) отправляется не раз в миллисекунду, а гораздо реже (в элементарном окошке считаем количество отправок).

Отправлять раз в 15 миллисекунд 64*15 байтов.

Понятно, но это не годится. На каждый отправленный пакет должен быть ответ. После каждой отправки ждём ответа.

Возьмите ddk´ный bulk драйвер от XP, например. Там посылается за раз 4Кб буфер (если память не изменяет) и скорость порядка 800 Кб/с можно запросто получить.

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

Для USB интерфейса алгоритм обмена типа "запрос-ответ" категорически не годится потому что дает низкую скорость.
Используйте 2 независимых потока: входной и выходной, причем в pc и девайсе должна быть обеспечена буферизация и чем глубже тем лучше. По другому серьезную скорость не получите.

А какой размер ответа?
Если я все правильно понимаю то котроллер будет NAKать IN трансферы меньше 62 байт если прошло меньше 16 мс после успешного трансфера.

Так и не смог найти код по теме.

В целом, тут два пути для оптимизации.
длл драйвера должна экспортировать функцию

FT_SetLatencyTimer(...)

с ее помощью можно изменить время ожидания между двумя последовательными IN трансферами меньше 62 байт. (минимум 2 мс)

И еще должна быть функция

FT_SetChars(...)

которая позволяет установить символ события. После получения такого символа в OUT пакете, котроллер должен ответить байтами статуса и при получении IN запроса заслать до 62 байт данных без задержки.

Это, конечно, если я ничего не перепутал.

Попробуйте послать пакет 62 байта.
Как-то похоже на latency timer, но тот правда работает на передачу в PC. FTDI добавляет 2 своих статусных байта на каждый пакет, соответственно в вашем случае посылает 2 bulk пакета. Второй через время latency timer, которое по умолчанию 16мс.
Почитайте AN232B-04 Data Throughput,Latency and Handshaking.

Это похоже на квант планировщика Виндов.

И то правда.

Как то не замечали таких траблов с FTDI при обмене через ftdi.dll.


XP Embedded не поможет, поскольку нечем от Professional не отличается. в этой части Real time это WinCe, но это другая ОСь.