Не фантастика сам лично через виртуальный COM порт загонял в компьютер 1 ГБайт за 90 секунд

УРА! Нашел эту самую злополучную задержку!
В доп. настройках ком порта FTDI.
В параметре "Время ожидания (мсек)" стояло именно 17!
Поставил 1 и задержка действительно стала 1мс, правда иногда скачет до 2-х мс, но это видать винда чудит.
В результате удалось получить скорость приёма ~278сек. Далеко от идеала но всёже лучше чем не 1310с
Кстати, уменьшение параметра "Буфер приёма/передачи (Байты)" с 4096 до 512 не даёт ни какого эффекта.

Сейчас думаю как ещё уменьшить время приёма.
1. Увеличить скорость до 3Mb/s - эффект предсказуем.
2. Увеличить размер передаваемой пачки до 1024,2048 или 4096 байт.

Как думаете существенно ли повлияет увеличение размера буфера на время передачи?
Т.к. изменение буфера довольно кропотливый процесс и не хочется зря время тратить.


Как же это возможно? Ведь скрость должна быть ~120Mb/s!

У вас в одну сторону буфер должен быть 512 байт, а в другую - 1 байт. Возможно, сейчас тормозит именно передающая команды сторона

Дык, гадюка, буфер меньше 64 байт ни на прём ни на передачу поставить не даёт!
Но даже если ставлю буфер передачи 64 байта, эффекта никакого.
И потом, приём в ПК это всего лишь один из режимов. Позже нужно будет и обратно 32МБ гнать.
Как размеры буферов менять на лету?
Я бы лучше "Время ожидания (мсек)" поставил в 0 но меньше 1 тоже не даёт.

Вы когда отправляете запрос с ПС на МК пишете 1 байт в FT. Драйвер FT берет байт и ждет, пока вы еще что нибудь в него запишите. Не дождавшись - отправляет этот 1 байт, и только потом МК начинает гнать ответ. Вот это время ожидания и есть "Время ожидания (мсек)". Попробуйте подключиться к FT через его родной интерфейс (из .dll), там может быть функция принудительной отправки буфера.

Оооо Спасибо!!! Теперь становится понятно что к чему.
А где искать эту .dll и описание её функций?

тут и тут

OK.

Еще тут посмотрите

Шото не нашёл функции принудительной выдачи буфера

Как вариант, настроить буфер на 64 байта и плюнуть туда 64 байта.
А проц пусть обрабатывает первый, а остальные игнорирует. На будущее и они пригодятся

Ну да, 64 байта уйдут то быстрее чем 1 мс, а если позже нужно будет увеличить выходной буфер как это сделать на лету?

Вертуальный СОМ порт это мост USB<->UART.
Т.е. с одной стороны у вас ножки USB, а стругой - ножки UART.
Эта кортинка справедлива только если вы реально что-то выдаете на ножки UART. И в этой картинке (окне) вы задаете с какой скоростью будут идти данные на ножках UART.
И значение этой скорости передается в микросхему в дескрипторах USB.
Если использовать аппаратный мост (типа FT232) то получается, что не возможно выйти за рамки этих настроек.
Если виртуальный СОМ порт реализовать на микроконтроллере, то эти настройки (передаваемые в дескрипторах) можно проигнорировать и сделать все по-своему.
У меня так и было сделано. А данные гнались из внутреннего ОЗУ микроконтроллера по HIGH-SPEED USB.

Аааа, ну тогда конечно. А мне приходится с мс FT232R бороться.



Кажется я поторопился с предсказуемостью
Если устанавливаю скорость больше чем 2Mb/s то, ниче не работает
Токи комп не понимает толи проц чегото не успевает

Я тоже, но там есть функции Purge,Clear и EventSymbol в настройках. Возможно что то из этого может помочь. Еще там есть настройки таймаутов для read/write (отдельно). Тоже может помочь (если в 0 выкрутить). Еще там есть возможность принудительно отправить пакет от FT к PC (если изменить состояние любой из управляющих ног на RS232 стороне FT), к сожалению не описанна возможность принудительно отправить что либо в обратную сторону