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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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


Еще раз: едва ли кто-нибудь, находясь в здравом уме и трезвой памяти, станет работать с COM-портом (пусть и виртуальным) огромными блоками.
Так что это предложение выполняется автоматически в 99% случаев.

Перечитайте первый пост:

Или вы не читатель?

Да перечитал уже, но решил оставить: печально, но вы с ТС попали в 1%.

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

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

Звук пишу в DataFlash.

Так у нее страница не больше килобайта с копейками.

Не помогает.
Зато у нее два буфера и писать можно не прерываясь.

Кстати, как заюзать библиотеку предложенную -SANYCH- из поста №7?

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


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

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

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

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

И на строительство бомбоубежища - а вдруг метеорит упадет...

Ну да, еще трансиверы с одной и с другой стороны. И разъемы, да.

Да, протокол - это своего рода "бомбоубежище". И важность его создания нельзя недооценивать.
Не удивлюсь, если выяснится, что полетное задание на Фобос-Грунт заливали по вашей методе


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

Это какой же кривизны надо иметь руки ? Трансиверы валят фронты ? Отлично, они это и должны делать. Однако и под нагрузкой исправный трансивер обязан обеспечивать нормированные параметры фронтов. Если, конечно, кто-то не пытается 120кбодный использовать на 230400 или выше. Битовые скорости различаются ? Так кто ж виноват, что не умеет выставить делитель ? Если передача по RS-232 не получается, надо не с блочностью и квитированием играться, а начать с ДНК. Другое дело, конечно, если речь идет о работе в условиях сильных промышленных помех. Но тема началась вообще с USB, так что о промоборудовании и разговора нет. А в условиях рабочего стола, несколько метров кабеля, на 115200 - это работает как часы. Без всяких потусторонних "досадных мелочей".

Мне попадались на материнских платах и такие, которые 115200 умудрялись изрядно заваливать.


Разумеется. Только это не повод выбросить проверку целостности и квитирование, если получается. На красный свет дорогу переходить тоже получается.


Чем это USB не годится для промоборудования?


В условиях рабочего стола - пожалуйста, делайте что душе угодно. А вот если проектируется оборудование, которое должно работать и на других столах тоже, то такой подход неприемлем.

До такой степени, чтобы не работали стандартные же приемники ? Позвольте не поверить. Кому нужен такой COM, к которому нельзя подключить модем ? А если скопом разглядывать, да, завалены (там нередко и дополнительные конденсаторы стояли).

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

Да хотя бы нефиксирующимися разъемами и весьма ограниченным расстоянием между устройствами.

Еще раз - если RS-232 не работает, надо не с блочностью ковыряться, а разбираться, почему не работают элементарные вещи. Для контроля целостности есть и иные методы, а простая передача файла по RS-232 должна работать без костылей.

Скажем так, работали, но на грани. И редкие ошибки уже были. Модем как раз можно было подключить без проблем - верхние протоколы ведь отрабатывали.


Бывают и вполне себе фиксирующиеся. И герметичные до кучи.


Еще раз: если разобрались с элементарными вещами и передали файл без костылей, то это еще не повод расслабляться и чувствовать себя в лесу.

Помимо чисто аппаратных проблем бывают еще и программные и программно-аппаратные (собственно, с чего тема и начиналась). Приведу пример из жизни:
в какой-то момент времени мой домашний комп стал терять байты при приеме через COM-порт. Впоследствии выяснилось, что виноват был помирающий хард
(умирало что-то в интерфейсной части, в результате чего на короткие промежутки времени драйвер SATA глухо подвешивал систему). Так вот, это не мешало
мне спокойно работать со своим железом через "глючащий" порт. Простой прием бы накрылся, но формально компьютер был жив.

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


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


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

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

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

До тех пор пока эти буфера не заполнятся. А потом надо бы дождаться, пока запись в DF из первого буфера закончится, прежде чем начинать снова в него лить из PC. Иначе возможны плавающие глюки

Например, не полностью реализованной сигнализацией (CTS упущен, если я правильно помню).

FT232 (без буквы R), и первый драйвер COM порта от FTDI появились задолго до появления CDC. Да и протокол у FT232 скорее всего отличается от протокола CDC (по той же причине). Так что скорее всего драйвера COM порта от FDTI не сидят на CDC (хотя конечно все возможно )

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