FT232R - как передать большой пакет Опции

[Alt.F4]

Добрый день.
Столкнулся с проблемой передачи пакета 250КБ при помощи терминальной программы и FT232R на скорости 115200.
1) Программа RS232pro v3.30 виснет и шлет байты с огромными паузами, хотя с реальным СОМ-портом вопросов нет.
2) Программа Advanced Serial Port вроде как шлет, но на выходе FT232R теряется половина байтов.
Думаю, что переполянется внутренний буфер FT232R.
Как решить проблему?
Спасибо.

Сообщение отредактировал Alt.F4 - Mar 10 2012, 19:15

[Alt.F4]

Заюзал я короче нормальный сом-порт стационарного РС. При острой необходимости виртуального порта на ноуте буду пытаться передавать по 8кб.

[aaarrr]

При острой необходимости виртуального порта на ноуте буду пытаться передавать по 8кб.

По-моему, и 8 уже изрядный перебор. Чем обусловлена потребность работы такими большими блоками?

[rx3apf]

По-моему, и 8 уже изрядный перебор. Чем обусловлена потребность работы такими большими блоками?

А зачем вообще без необходимости использовать поблочную работу ? Если, например, есть какой-то файл и его надо передать в устройство - пусть на максимальной скорости и летит, о блочности позаботится сама микросхема (исходя из размера своих буферов). Какая-то все ж странная проблема - я не наблюдал такого ни с простой передаче потока (когда микроконтроллер заведомо успевал обработать), без управления потоком. Когда же не успевал - использовал управление, и опять же все байт в байт. просто "copy <файл> COM<n>" и ни о чем не приходилось задумываться.

Заюзал я короче нормальный сом-порт стационарного РС. При острой необходимости виртуального порта на ноуте буду пытаться передавать по 8кб.

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

[aaarrr]

А зачем вообще без необходимости использовать поблочную работу ?

Отправить 250кБайт просто на удачу? Обычно все же принято использовать квитирование, контроль целостности и т.п.

[rx3apf]

Отправить 250кБайт просто на удачу? Обычно все же принято использовать квитирование, контроль целостности и т.п.

Контроль целостности можно и по контрольной сумме внутри эти 250 кило. Это все ж кусок провода, а не радиоэфир или поганая телефонная линия.

[aaarrr]

Контроль целостности можно и по контрольной сумме внутри эти 250 кило. Это все ж кусок провода, а не радиоэфир или поганая телефонная линия.

И потратить еще 30 секунд на повторную посылку, ежели вдруг сломалось. Если мы говорим о RS-232, то это отнюдь не просто кусок провода.

[=AK=]

И потратить еще 30 секунд на повторную посылку, ежели вдруг сломалось. Если мы говорим о RS-232, то это отнюдь не просто кусок провода.

Откуда у вас 30 сек взялись? USB FS типично перекачает 250 кБ за пару секунд. Битые пакеты в балке перезапрашиваются автоматически, потому вероятность, что "ежели вдруг сломалось" исчезающе мала. Если бы не баг в драйвере, то разбивать файл на мелкие блоки не имело бы ни малейшего смысла: это лишний гемморой и ненужный оверхед, достаточно проверять целостность всего файла.

Совершенно не логично. Эмуляция последовательного порта (весьма урезанная и убогая) - это лишь малая часть CDC.

Вот именно поэтому весьма вероятно, что FTDI VCP пристыкуется к CDC, поскольку тогда пользователю предоставляется вся стандартная функциональность CDC, а усилия для этого от FTDI требуются мизерные. Вот в этом и состоит логика всякого вменяемого разработчика: не изобретать велосипед там, где предоставляется стандартный сервис достаточно хорошего качества.

Данные гонять можно, но для построения полноценного виртуального порта она неприменима.

А что же тогда по-вашему есть "полноценный виртульный порт"? Чем вас не устраивают виртуальные порты, появляющиеся при использовании драйверов класса CDC (если не считать бага в имплементации)?

[rx3apf]

Откуда у вас 30 сек взялись? USB FS типично перекачает 250 кБ за пару секунд. Битые пакеты в балке перезапрашиваются автоматически, потому вероятность, что "ежели вдруг сломалось" исчезающе мала. Если бы не баг в драйвере, то разбивать файл на мелкие блоки не имело бы ни малейшего смысла: это лишний гемморой и ненужный оверхед, достаточно проверять целостность всего файла.

Мы там уже плавно перешли к "настоящему" RS-232. Но и в том, и другом (USB->COM) случае, если заказана скорость UART 115200, 250 кб будут передаваться больше 25 секунд (не бывает мостов с буфером в четверть мегабайта).

И по факту все работает (FT232, FT2232) без ограничений на длину блока 8 кило.