firstvald 15 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба Хотя что - то подобное в нескольких темах видел - точно такого - нет. Вижу: при обмене (запрос ответ) через FTDI232RL происходит потеря окончания посылки ответа от прибора. Причем посылки-то небольшие : байт по 16. Игры с настройками тайм-аутов и величины буфера вообще никак не влияют. Данные от машины в сторону прибора доходят без ошибок. В передаче в сторону машины время от времени не хватает нескорльких байт в конце. По статистике получается самой плохой скорость 19200, на ней бъется в среднем каждый 50 цикл. На других скоростях сбой примерно раз в 200-300 циклов (и от скорости не зависит). Обмен редкий - цикл в секунду. Кто какую статистику получал? Какую микруху понадежнее использовать? Насколько подвержено этому 2102/3? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба В FTDI232, кроме выводов RX и TX, есть еще сигнальные выводы управления потоком (как в COM-порту). Вы их используете или нет? В любом случае, не стоит оставлять их болтаться "в воздухе"... ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 15 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба В FTDI232, кроме выводов RX и TX, есть еще сигнальные выводы управления потоком (как в COM-порту). Вы их используете или нет? В любом случае, не стоит оставлять их болтаться "в воздухе"... ;) Не, они у меня висят. Как висят в pdf от FTDI. Попробую сейчас CTS посадить куда. Только не в этом дело . Вот смотрю 9600 - 1600 циклов обмена без ошибок. Тут же на 19200 8 сбоев на 380 циклах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба Не, они у меня висят. Как висят в pdf от FTDI. Если висят, то нужно отключить управление потоком в ПК. Но проще соединить между собой RTS-CTS и DTR-DSR, чтобы не думать на эту тему. Скорости передачи и объемы у Вас небольшие, поэтому управление потоком можно не использовать. Оставлять же висящими управляющие входы не стоит. Хотя там, наверняка, есть внутренние подтяжки, лучше подстраховаться от наводок... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 15 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба Если висят, то нужно отключить управление потоком в ПК. Но проще соединить между собой RTS-CTS и DTR-DSR, чтобы не думать на эту тему. Скорости передачи и объемы у Вас небольшие, поэтому управление потоком можно не использовать. Оставлять же висящими управляющие входы не стоит. Хотя там, наверняка, есть внутренние подтяжки, лучше подстраховаться от наводок... Управление потоком никогда не использую. Сразу же его в dcb отключаю. Нет, не влияет заведение этих сигналов на питание на обмен (заводил CTS DSR), как сбивалось, так и сбивается. Буду выяснять: вообще тот конец посылки, который откусывается , он когда -нибудь выходит из FTDI, или вообще остается в ней навеки? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба Нет, не влияет заведение этих сигналов на питание на обмен (заводил CTS DSR), как сбивалось, так и сбивается. Почему на питание-то? Сигналы TTL инвертированные. Нужно на землю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 15 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба Почему на питание-то? Сигналы TTL инвертированные. Нужно на землю. А это уже не важно. Они просто доходят как битовые сигналы в комп,а уже там если используются, то тогда надо и думать каким его ставить. Я вот вижу: при CTS на землю - доходит в комп как 1 и так же DSR. Кстати, число сбоев не зависит от того, куда затянуть выводы. А вообще - общее впечатление - кошмар! Никакого ответственного оборудования (медицинского, промышленного) через такой порт делать нельзя. Что -то не так: "открывай кашелку, доставай сумочку", вытащить разъем из компа, закрыть программу, вставить разъем в комп, запустить программу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vetal 0 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба Используем чипы и фирменные шнурки от FTDI на скоростях от 2400 до 750000(трафик от 20б/с до 100кб/с) - указанных симптомов не наблюдалось даже при прогоне 24/7. Ищите ошибки в своих программах. Настоятельно рекомендую посмотреть наличие 0x00 перед местами возникновения потенциальных потерь.( Как ни странно - весьма распространенная ошибка :) ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба Никакого ответственного оборудования (медицинского, промышленного) через такой порт делать нельзя. Вы не торопитесь с выводами. Мы, также, FTDI давно и успешно используем. Что-то не так в вашей схеме или программе. Чудес-то не бывает. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 15 13 декабря, 2009 Опубликовано 13 декабря, 2009 (изменено) · Жалоба Вы не торопитесь с выводами. Мы, также, FTDI давно и успешно используем. Что-то не так в вашей схеме или программе. Чудес-то не бывает. :) Бывает , бывает! Вот прогнал скорость 19200 без паритета - 1616 циклов без ошибок (вот уже 2180 без ошибок :) ). Значит FTDI не всегда удается передавать посылки с использованием паритета. А на 38400 и 9600 удается! Вот так вот. 0 не появляются, я гоняю сырые байты - MODBUS RTU, он очень критичен ко всему и если в канале какие затыки сразу вытрясает их. Пришлось, правда, практически до безобразия, расширить допустимый интервал между байтами на стороне компа, но это на маленьких пакетах никак не улучшило дело. Изменено 13 декабря, 2009 пользователем firstvald Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 13 декабря, 2009 Опубликовано 13 декабря, 2009 · Жалоба Бывает , бывает! Вот прогнал скорость 19200 без паритета - 1616 циклов без ошибок (вот уже 2180 без ошибок ). Значит FTDI не всегда удается передавать посылки с использованием паритета. А на 38400 и 9600 удается! Вот так вот Ну Вы даете. :) Так это проблемы использования MODBUS под Win, а не FTDI. Она передает и принимает все как надо. И, насколько мне известно, паритет она за Вас считать/проверять не будет - это должны делать передающие/принимающие модули. Могу только посоветовать установить бит паритета в 1 постоянно. Модбас такой режим допускает. Установить таймаут ожидания ответа порядка 100мс. А так как винда может, все равно, вставить паузу в непрерывный поток байтов при приеме/передаче - придется смириться с каким-то количеством ошибок и организовать повторные запросы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 15 14 декабря, 2009 Опубликовано 14 декабря, 2009 · Жалоба Ну Вы даете. :) Так это проблемы использования MODBUS под Win, а не FTDI. Она передает и принимает все как надо. И, насколько мне известно, паритет она за Вас считать/проверять не будет - это должны делать передающие/принимающие модули. Могу только посоветовать установить бит паритета в 1 постоянно. Модбас такой режим допускает. Установить таймаут ожидания ответа порядка 100мс. А так как винда может, все равно, вставить паузу в непрерывный поток байтов при приеме/передаче - придется смириться с каким-то количеством ошибок и организовать повторные запросы. Нет не так. MODBUS под виндой спокойно работает во всем диапазоне скоростей. Правда, нужно очень аккуратно заполнять для каждой скорости структуру тайм аутов. И вовсе не теми числами, которые туда просятся теоретически Дело тут не в MODBUS - он просто обнаруживает те ошибки , о которых, гоняя символьные посылки, можно было до пенсии и не подозревать. Паритет должен проскакивать через FTDI насквозь без изменения. Так, как его сформировал передатчик. И мы должны иметь возможность работать со всеми возможными сочетаниями параметров связи. Получается, что надо нащупать какие работают , а какие - с вопросами. Чтобы заказчику потом объяснить - ты сюда не ходи, снег башка попадет. С тайм аутами да, очень аккуратно надо их выставить. Но то , что работало во всех диапазонах скоростей через честный RS, должно работать и сейчас (возможно некоторые тайм ауты надо увеличить - расстояние между байтами, скорее всего - да). Иначе скандал - RS в каком-нибудь небуке не бывает , а в цеху надо посмотреть. Начинаем смотреть и выясняется, что все посмотреть то и нельзя! У меня уже несколько раз была мысль о большом компе на тележке Персоналом, как бред не воспринимается. Про паузы. Непрерывные потоки не смотрел. На, скажем, в 256 байт, выходящих из машины, разрывов и пауз не видел ни разу. Этот вопрос я первым делом проверял. При приеме, уже написал, что если заполнить аккуратно структуру тайм аутов, каких - то провалов не наблюдается (но не на непрерывных данных). Но, это при значениях в структурах, которые сильно отличаются от того, что бы туда надо было прописать подсчитав карандашиком. Тайм ауты винда точно не считает. Вот интересно - окуда FTDI берет тактовые импульсы? ВМ их из кварца брала. А у этой? Буду еще смотреть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 14 декабря, 2009 Опубликовано 14 декабря, 2009 · Жалоба Нет не так. MODBUS под виндой спокойно работает во всем диапазоне скоростей. Правда, нужно очень аккуратно заполнять для каждой скорости структуру тайм аутов. И вовсе не теми числами, которые туда просятся теоретически. Дело тут не в MODBUS - он просто обнаруживает те ошибки , о которых, гоняя символьные посылки, можно было до пенсии и не подозревать... Что-то не то Вы пишите. FT232 вполне нормальная, надежная м/c. Кучу серийных устройств на ней реализовали. Не припомню что-то проблем, о которых Вы здесь говорите. Все нормально работает, на всех режимах и скоростях. Генератор у нее внутренний, внешний кварц не требуется. Этим она и привлекательна. В ДШ все описано... Межбайтовый и межфреймовый таймауты для MODBUS прописаны в самом протоколе, и устанавливать его по своему усмотрению - есть нарушение со всеми вытекающими... Так что, в первую очередь, ищите ошибки в своих программах и схемах, а не там где их нет. ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jorikdima 0 14 декабря, 2009 Опубликовано 14 декабря, 2009 · Жалоба Используем чипы и фирменные шнурки от FTDI на скоростях от 2400 до 750000(трафик от 20б/с до 100кб/с) - указанных симптомов не наблюдалось даже при прогоне 24/7. Ищите ошибки в своих программах. Настоятельно рекомендую посмотреть наличие 0x00 перед местами возникновения потенциальных потерь.( Как ни странно - весьма распространенная ошибка :) ) Вы не торопитесь с выводами. Мы, также, FTDI давно и успешно используем. Что-то не так в вашей схеме или программе. Чудес-то не бывает. :) Согласен. Еще предложение. Возможно причина в несогласованносте скоростей UART у FTDI и в вашем МК из-за неточности частоты, тактирующей UART МК. На FTDI 19200 у вас 19100 например, как правило в доках на МК есть таблицы вероятности ошибок в зависимости от частоты и бодрэйта. Но там речь идет о единицах процентов в худшем случае. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость @Ark 14 декабря, 2009 Опубликовано 14 декабря, 2009 · Жалоба ... как правило в доках на МК есть таблицы вероятности ошибок в зависимости от частоты и бодрэйта. Но там речь идет о единицах процентов в худшем случае. Вполне вероятная причина. У внутреннего генератора FT232, также, возможно отклонение +/- 0,16% от номинала. Если скорости UART-тов не совпадут, примерно, на 2% или более - могут возникнуть ошибки... И еще. Автор пишет об ошибках только при передаче в компьютер. Возможно, фронты сигнала "завалены" на линии передатчика UART MK, по каким-то причинам. IMHO, нужно сначала проверять работу схемы, а не наводить статистику. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
