[aaarrr 68]

Однако и под нагрузкой исправный трансивер обязан обеспечивать нормированные параметры фронтов. Если, конечно, кто-то не пытается 120кбодный использовать на 230400 или выше.

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

 

Если передача по RS-232 не получается, надо не с блочностью и квитированием играться, а начать с ДНК.

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

 

Но тема началась вообще с USB, так что о промоборудовании и разговора нет.

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

 

А в условиях рабочего стола, несколько метров кабеля, на 115200 - это работает как часы.

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

[rx3apf 0]

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

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

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

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

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

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

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

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

[aaarrr 68]

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

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

 

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

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

 

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

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

 

Помимо чисто аппаратных проблем бывают еще и программные и программно-аппаратные (собственно, с чего тема и начиналась). Приведу пример из жизни:

в какой-то момент времени мой домашний комп стал терять байты при приеме через COM-порт. Впоследствии выяснилось, что виноват был помирающий хард

(умирало что-то в интерфейсной части, в результате чего на короткие промежутки времени драйвер SATA глухо подвешивал систему). Так вот, это не мешало

мне спокойно работать со своим железом через "глючащий" порт. Простой прием бы накрылся, но формально компьютер был жив.

[=AK= 10]

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

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

 

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

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

 

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

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

[rx3apf 0]

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

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

 

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

 

[xvr 12]

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

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

 

[aaarrr 68]

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

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

[xvr 12]

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

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

 

 

[fox2trot 0]

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