Хотя что - то подобное в нескольких темах видел - точно такого - нет.

Вижу: при обмене (запрос ответ) через FTDI232RL происходит потеря окончания посылки ответа от прибора. Причем посылки-то небольшие : байт по 16.
Игры с настройками тайм-аутов и величины буфера вообще никак не влияют. Данные от машины в сторону прибора доходят без ошибок. В передаче в сторону машины время от времени не хватает нескорльких байт в конце.

По статистике получается самой плохой скорость 19200, на ней бъется в среднем каждый 50 цикл. На других скоростях сбой примерно раз в 200-300 циклов (и от скорости не зависит). Обмен редкий - цикл в секунду.

Кто какую статистику получал? Какую микруху понадежнее использовать? Насколько подвержено этому 2102/3?

В FTDI232, кроме выводов RX и TX, есть еще сигнальные выводы управления потоком (как в COM-порту). Вы их используете или нет? В любом случае, не стоит оставлять их болтаться "в воздухе"...

Не, они у меня висят. Как висят в pdf от FTDI. Попробую сейчас CTS посадить куда. Только не в этом дело . Вот смотрю 9600 - 1600 циклов обмена без ошибок. Тут же на 19200 8 сбоев на 380 циклах.

Если висят, то нужно отключить управление потоком в ПК. Но проще соединить между собой RTS-CTS и DTR-DSR, чтобы не думать на эту тему. Скорости передачи и объемы у Вас небольшие, поэтому управление потоком можно не использовать. Оставлять же висящими управляющие входы не стоит. Хотя там, наверняка, есть внутренние подтяжки, лучше подстраховаться от наводок...

Управление потоком никогда не использую. Сразу же его в dcb отключаю.

Нет, не влияет заведение этих сигналов на питание на обмен (заводил CTS DSR), как сбивалось, так и сбивается.

Буду выяснять: вообще тот конец посылки, который откусывается , он когда -нибудь выходит из FTDI, или вообще остается в ней навеки?

Почему на питание-то? Сигналы TTL инвертированные. Нужно на землю.

А это уже не важно. Они просто доходят как битовые сигналы в комп,а уже там если используются, то тогда надо и думать каким его ставить.

Я вот вижу: при CTS на землю - доходит в комп как 1 и так же DSR.

Кстати, число сбоев не зависит от того, куда затянуть выводы.

А вообще - общее впечатление - кошмар! Никакого ответственного оборудования (медицинского, промышленного) через такой порт делать нельзя. Что -то не так: "открывай кашелку, доставай сумочку", вытащить разъем из компа, закрыть программу, вставить разъем в комп, запустить программу.

Используем чипы и фирменные шнурки от FTDI на скоростях от 2400 до 750000(трафик от 20б/с до 100кб/с) - указанных симптомов не наблюдалось даже при прогоне 24/7.
Ищите ошибки в своих программах. Настоятельно рекомендую посмотреть наличие 0x00 перед местами возникновения потенциальных потерь.( Как ни странно - весьма распространенная ошибка )

Вы не торопитесь с выводами. Мы, также, FTDI давно и успешно используем. Что-то не так в вашей схеме или программе. Чудес-то не бывает.

Бывает , бывает! Вот прогнал скорость 19200 без паритета - 1616 циклов без ошибок (вот уже 2180 без ошибок ). Значит FTDI не всегда удается передавать посылки с использованием паритета. А на 38400 и 9600 удается! Вот так вот.

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

Ну Вы даете. Так это проблемы использования MODBUS под Win, а не FTDI. Она передает и принимает все как надо. И, насколько мне известно, паритет она за Вас считать/проверять не будет - это должны делать передающие/принимающие модули. Могу только посоветовать установить бит паритета в 1 постоянно. Модбас такой режим допускает. Установить таймаут ожидания ответа порядка 100мс. А так как винда может, все равно, вставить паузу в непрерывный поток байтов при приеме/передаче - придется смириться с каким-то количеством ошибок и организовать повторные запросы.

Нет не так. MODBUS под виндой спокойно работает во всем диапазоне скоростей. Правда, нужно очень аккуратно заполнять для каждой скорости структуру тайм аутов. И вовсе не теми числами, которые туда просятся теоретически

Дело тут не в MODBUS - он просто обнаруживает те ошибки , о которых, гоняя символьные посылки, можно было до пенсии и не подозревать.

Паритет должен проскакивать через FTDI насквозь без изменения. Так, как его сформировал передатчик. И мы должны иметь возможность работать со всеми возможными сочетаниями параметров связи. Получается, что надо нащупать какие работают , а какие - с вопросами. Чтобы заказчику потом объяснить - ты сюда не ходи, снег башка попадет.

С тайм аутами да, очень аккуратно надо их выставить. Но то , что работало во всех диапазонах скоростей через честный RS, должно работать и сейчас (возможно некоторые тайм ауты надо увеличить - расстояние между байтами, скорее всего - да). Иначе скандал - RS в каком-нибудь небуке не бывает , а в цеху надо посмотреть. Начинаем смотреть и выясняется, что все посмотреть то и нельзя! У меня уже несколько раз была мысль о большом компе на тележке Персоналом, как бред не воспринимается.

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

Вот интересно - окуда FTDI берет тактовые импульсы? ВМ их из кварца брала. А у этой?

Буду еще смотреть.

Что-то не то Вы пишите. FT232 вполне нормальная, надежная м/c. Кучу серийных устройств на ней реализовали. Не припомню что-то проблем, о которых Вы здесь говорите. Все нормально работает, на всех режимах и скоростях. Генератор у нее внутренний, внешний кварц не требуется. Этим она и привлекательна. В ДШ все описано...
Межбайтовый и межфреймовый таймауты для MODBUS прописаны в самом протоколе, и устанавливать его по своему усмотрению - есть нарушение со всеми вытекающими... Так что, в первую очередь, ищите ошибки в своих программах и схемах, а не там где их нет.

Согласен.
Еще предложение. Возможно причина в несогласованносте скоростей UART у FTDI и в вашем МК из-за неточности частоты, тактирующей UART МК. На FTDI 19200 у вас 19100 например, как правило в доках на МК есть таблицы вероятности ошибок в зависимости от частоты и бодрэйта. Но там речь идет о единицах процентов в худшем случае.

Вполне вероятная причина. У внутреннего генератора FT232, также, возможно отклонение +/- 0,16% от номинала. Если скорости UART-тов не совпадут, примерно, на 2% или более - могут возникнуть ошибки...
И еще. Автор пишет об ошибках только при передаче в компьютер. Возможно, фронты сигнала "завалены" на линии передатчика UART MK, по каким-то причинам. IMHO, нужно сначала проверять работу схемы, а не наводить статистику.

Все как надо подтянуто. Дело не в фронтах. На скоростях 115200 работает. Ессно скорость 19200 правильно генерируется. В серии у нас на многих сотнях метров через кабель бегает. Наиболее вероятно - отклонение генератора в микросхеме, но это только догадка.
Статистикой только и надо заниматься. Если нет вопросов на макете - могут быть в серии, а если что-то иногда на макете проскакивает - серия будет полностью неработоспособной. Насмотрелся на серийные буржуйские изделия которые на поверку не работают когда с ними не на столе и не терминалом играешься и они продаюся! Пока придется карту минных полей составлять - где не работает

Я вижу причины Вы не хотите искать. Ну тогда занимайтесь догадками и статистикой, составляйте "карту минных полей"...
Удачи!

Удалось обмен отладить - в структуре тайм-аутов тайм-ауты, начиная со скорости 19200 (хотя не понятно: для 38400 57600 115200 можно оставить то, что есть), пришлось увеличить в два раза по сравнению с теми значениями, при которых обмен работает нормально через обычный RS (замечу еще раз , что нормально обмен работает не при вычисленных значениях, а при подобранных, винда тайм-ауты считает практически никак, а менее 10 мс вообще никак).

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

В старых разработках, которые работали через RS, а теперь возможно будут работать через мост или в устройство вделывается мост и устройство становится как-бы USB, возможно, во внешнем софте придется подкорректировать константы в структурах тайм-аутов.

Чудеса с паритетом запишем пока в загадки, возможно немного времени не хватало, но это надо обдумать.

Сдается мне, что вы наотрез не хотите смириться с тем, что вы работаете с контроллером шины USB, имеющем интерфейс UART, а не наоборот.
Замирания 20-1000мс(и хуже) - совершенно нормальная ситуация при работе под управлением ОС семейства Windows
Битовая скорость внешнего физического интерфейса(uart) и скорость обмена(что применимо и для задержек) информацией по шине USB имеют очень слабую связь, которая больше влияет на трафик, чем на задержки в отличие от наличия встроенного контроллера!

Равно как и при работе с удаленным(сетевым) последовательным портом задержки могут доходить до нескольких секунд.

Конечно не хочу мириться! Был RS232, можно было общаться с устройствами. А сейчас получается такая ситуация, что надежно общаться с устройством просто не через чего! Нету такой дырки в компьюторе! Одну засопливили, а новой не просверлили! Вернее просверлили, но не ту и не там.

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

Если вам нужна более жесткая времянка при работе с ЮСБ - пишите свой драйвер к вашему девайсу, FTDI вам тут не грозился этого обеспечить.

Так и на RL можно кварц повесить, что мешает?

Не понял, вы не в курсе, что FTDI и прочие переходники USB -> COM данные через bulk передают? А если знаете, то почему считаете, что может быть по другому?

Сделайте своё USB устройство и будет вам счастье. До 500 кбод вполне HID для этого подойдёт - драйверов не нужно будет.

Да нет. Так нельзя. В мире уже сложилось что общение с приборами происходит по последовательным протоколам. Ряд из них требует довольно жестких временных соотношений при обмене. Попытки отказаться в компьюторах от обычного послеледовательного порта приводят к тому, что такой компьютор тут же превращается в Dendy, годное только на MP и Word. Спасать лицо компам пытаются через оставшиеся дырки : локльную сеть и USB. Не работает ни то ни то.

То, как FTDI обменивается с компьютором должно быть абсолюно фиолетово, если смотреть на обмен со стороны API. А получается, что FTDI показывает в API свои заморочки. Это недоработка или небоежность FTDашного писателя. Если знаешь , что READFILE может вывалится потому что у тебя там что то не успело, но при этом сам обмен нормальный, нафига так писать?

1. USB - это последовательный протокол.
2. Жёсткие времянки д.б. возложены на контроллер.
3. Появление USB в компе - наоборот прорыв на новый уровень. USB-шные флешки тому пример. Другое дело, что люди в силу своей костности этого не замечают или не хотят замечать. Или скрывают т.о. своё незнание/неумение.

Я делаю свои девайсы подключающимися в USB как составное устройство HID+MassStorage. Это позволяет челу, который никогда не видел мой девайс и не знал о его существовании сразу начать с ним работать - воткнуть в USB и всё.
При этом появится окошечко с файлами (MassStorage), среди которых будет pdf-ка с описанием, исполняемый файл (exe-шник) для работы с моим девайсом и лог-файл, в который мой девайс складывает данные при работе без компа. Запустив exe-шник можно просмотреть лог, настроить мой девайс (через HID), а при подключении к объекту поуправлять и пополучать данные в реалтайме. Всякие модбасы, CAN и т.п., где нужны времянки, естественно формируются в моём девайсе.
При этом чела не заставили устанавливать никакие драйверы, не задали ему ни одного вопроса, не заставили выходить в инет, вводить коды активации и т.д. и т.п. И вообще у него не возникло никаких вопросов. Точнее возник только один - а почему другие так не делают?

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

Когда на МК нет ЮСБ или же обмен данными через ЮСБ настолько прост (малые объемы данных), что не хочется тратить время на реализацию ЮСБ в МК, а пользоваться UART, почему бы и нет???
Эти переходники довольно активно используютсявразличных приборах.

МК с USB уже $3 стоят. Причём это АРМ от STM.
При цене FTDI $2 (?) на МК $1 остаётся. Причём в этом случае будет 2 корпуса. Поэтому никакого смысла из-за экономии денег использовать МК без USB, при подключении к USB нет. Если уж так нравится, то можно эмулировать COM на МК с USB. Один раз сделал - и пусть кочует из проекта в проект...

А то, что они активно используются, это не есть хорошо...

у меня работает связка на 1 мбит
делиттель на FTDI принудительно на 3



ATMEGA8 _кварц _ 8MGZ обязательно от RC не рабоатла
пакет аж 32768 байт