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

[Alt.F4]

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

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

[rx3apf]

Управление потоком включено ?

[Alt.F4]

Отключено, на другой стороне юзаю только RXD и TXD (UART МК).
Да и он по большому счету там не нужен, работаю только в одну сторону (от ПК) и МК все успевает.

Сообщение отредактировал Alt.F4 - Mar 11 2012, 04:17

[Andreymai]

1. я сперва использовал PL-2303, но потом у него нашелся "косячек" - эта микруха иногда какие то лишние нули в поток добавляет (выявляется только на больших объемах данных - 200 кБ) потом перешел на CP2103 и проблема пропала.
2. еще надо проверить выводы RTS/CTS - не висят ли в воздухе

[Alt.F4]

еще надо проверить выводы RTS/CTS - не висят ли в воздухе

по мануалу они могут висеть.
Вся проблема, как я думаю, в тупом переполении буфера микрухи, т.е. по юсб пакет быстро передается на фт232, которая начинает его передавать на скорости много меньшей.
Верна ли эта версия? Если да, то осталось узнать размер буфера и передавать пакет частями.

Сообщение отредактировал Alt.F4 - Mar 11 2012, 07:38

[Vasily_]

Попробуйте в настройках порта FTDI поменять латенци таймер, по умолчанию стоит 16 поставьте например 2.

[-SANYCH-]

Когда работал с FT232 тоже столкнулся с проблемой. Когда читал с устройства переданные данные на скорости 115200 то получал в конце пакета ноли или отфонарные символы. Решить эту проблему удалась использовав библиотеку FTDI.

Прикрепленные файлы

 D2XXAPP.ZIP ( 30.73 килобайт ) Кол-во скачиваний: 22

 

[rx3apf]

Вся проблема, как я думаю, в тупом переполении буфера микрухи, т.е. по юсб пакет быстро передается на фт232, которая начинает его передавать на скорости много меньшей.
Верна ли эта версия? Если да, то осталось узнать размер буфера и передавать пакет частями.

Крайне сомнительная версия. Буфера там маленькие (256/128 байтов), обмен по USB гораздо быстрее, чем типичный обмен по UART. Я подобного эффекта (потерь данных и замедления передачи) не наблюдал, используя и управление потоком (при 921600), и без управления (230400), правда, блоки не 250 кило, но десятки килобайтов лил. По простой "copy" и терминалом (teraterm).

[=AK=]

Столкнулся с проблемой передачи пакета 250КБ при помощи терминальной программы и FT232R на скорости 115200.

У винды наличествует баг в USB драйвере класса CDC. При попытке передать через виртуальный COM порт файл размером более 8 кбайт, Винда начинает глючить именно так, как вы описали. Я это проверял на Вынь 7 путем замены CDC драйвера на драйвер некой немецкой фирмы. Названия фирмы не помню, но не в этом суть: немецкий драйвер работал как часы, он без малейших глюков передавал файлы любого размера. Однако демо версия, котороую я гонял, имела ограничения по времени на 30 дней, а покупать рабочую версию за несколько тысяч евро меня жаба задушила. Поэтому я просто стал резать свои файлы на куски размером не более 8 кБайт и передавать файл кусками, что и вам советую.

Магическое число 8 кБайт - это размер буфера в USB драйвере. После заполнении буфера виндовский драйвер глючит, очевидно, по той причине, что мелкософтовские программисты опять облажались с указателями.

[aaarrr]

У винды наличествует баг в USB драйвере класса CDC.

А какая связь между CDC и FT232R, у которого свои драйверы?

[=AK=]

А какая связь между CDC и FT232R, у которого свои драйверы?

У FT232R есть выбор: или использовать их собственные драйверы D2XX, или работать с виртуальным СОМ портом (VCP). Поскольку ТС явственно озвучил, что работает с СОМ портом, то, очевидно, в конечном счете речь идет именно о виндовом драйвере класса CDC.

[aaarrr]

Поскольку ТС явственно озвучил, что работает с СОМ портом, то, очевидно, в конечном счете речь идет именно о виндовом драйвере класса CDC.

VCP - это тоже их собственные драйверы, к виндовому usbser.sys ни малейшего отношения они не имеют.

[=AK=]

VCP - это тоже их собственные драйверы, к виндовому usbser.sys ни малейшего отношения они не имеют.

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

[aaarrr]

Я полагаю, что VCP - это прослойка, которая в конечном счете все равно опирается на виндовые CDC драйвера.

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

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

Едва ли в каком-либо из использованных ТС терминалов данные отправляются столь экстравагантным способом (кусками более 8кБайт).

[=AK=]

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

У любого виртуального СОМ порта есть очень много общего с CDC. Поэтому, чтобы не изобретать велосипед, его логично сделать именно как прослойку между специфической железякой и CDC.

Едва ли в каком-либо из использованных ТС терминалов данные отправляются столь экстравагантным способом (кусками более 8кБайт).

Как они сейчас передаются - не представляет большого интереса. Интерес представляет то, как их надо передавать, чтобы не было глюков. Мое предложение - передавать блоками не более чем по 8 кБайт. Это гарантирует, что буфер виндового CDC драйвера никогда не переполнится, поскольку микрософтовский баг состоит именно в ошибочной обработке указателей буфера в ситуации, когда надо его "зациклить", т.е. перейти из конца буфера в начало. У немцев с этим проблем нет, они организовали FIFO при помощи кольцевого буфера корректно. А у мелкомягких с этим проблемы, поэтому до тех пор, пока буфер не заполнился, все работает, а после 8 кБайт - глюки.

Передача блоками по 8 кБайт гарантирует, что буфер никогда не переполнится. Окончание блока означает, что транзакция завершилась, поэтому для следующего блока драйвер перейдет в исходное состояние и начнет укладывать данные с начала буфера. А в случае передачи массива рамерами более 8 кБ без разбивки на блоки драйвер вынужден переходить из конца 8-килобайтного буфера в начало, а там у мелкомягких баг.