| |
 Не доходит концовка посылки от прибора через FTDI232 |
|
|
2 страниц 
1 2 >
|
 |
Ответов
(1 - 27)
|
Guest_@Ark_*
|
 Dec 13 2009, 16:54
|
Guests
|
В FTDI232, кроме выводов RX и TX, есть еще сигнальные выводы управления потоком (как в COM-порту). Вы их используете или нет? В любом случае, не стоит оставлять их болтаться "в воздухе"... 
|
|
|
|
|
|
|
Guest_@Ark_*
|
Dec 13 2009, 17:19
|
Guests
|
Цитата Не, они у меня висят. Как висят в pdf от FTDI. Если висят, то нужно отключить управление потоком в ПК. Но проще соединить между собой RTS-CTS и DTR-DSR, чтобы не думать на эту тему. Скорости передачи и объемы у Вас небольшие, поэтому управление потоком можно не использовать. Оставлять же висящими управляющие входы не стоит. Хотя там, наверняка, есть внутренние подтяжки, лучше подстраховаться от наводок...
|
|
|
|
|
|
|
|
Dec 13 2009, 17:37
|
Знающий
Группа: Свой
Сообщений: 580
Регистрация: 3-06-08
Пользователь №: 38 041
|
Цитата(@Ark @ Dec 13 2009, 20:19)  Если висят, то нужно отключить управление потоком в ПК. Но проще соединить между собой RTS-CTS и DTR-DSR, чтобы не думать на эту тему. Скорости передачи и объемы у Вас небольшие, поэтому управление потоком можно не использовать. Оставлять же висящими управляющие входы не стоит. Хотя там, наверняка, есть внутренние подтяжки, лучше подстраховаться от наводок... Управление потоком никогда не использую. Сразу же его в dcb отключаю. Нет, не влияет заведение этих сигналов на питание на обмен (заводил CTS DSR), как сбивалось, так и сбивается. Буду выяснять: вообще тот конец посылки, который откусывается , он когда -нибудь выходит из FTDI, или вообще остается в ней навеки?
|
|
|
|
|
|
|
Guest_@Ark_*
|
Dec 13 2009, 17:48
|
Guests
|
Цитата Нет, не влияет заведение этих сигналов на питание на обмен (заводил CTS DSR), как сбивалось, так и сбивается. Почему на питание-то? Сигналы TTL инвертированные. Нужно на землю.
|
|
|
|
|
|
|
|
Dec 13 2009, 18:38
|
Знающий
Группа: Свой
Сообщений: 580
Регистрация: 3-06-08
Пользователь №: 38 041
|
Цитата(@Ark @ Dec 13 2009, 20:48) Почему на питание-то? Сигналы TTL инвертированные. Нужно на землю. А это уже не важно. Они просто доходят как битовые сигналы в комп,а уже там если используются, то тогда надо и думать каким его ставить. Я вот вижу: при CTS на землю - доходит в комп как 1 и так же DSR. Кстати, число сбоев не зависит от того, куда затянуть выводы. А вообще - общее впечатление - кошмар! Никакого ответственного оборудования (медицинского, промышленного) через такой порт делать нельзя. Что -то не так: "открывай кашелку, доставай сумочку", вытащить разъем из компа, закрыть программу, вставить разъем в комп, запустить программу.
|
|
|
|
|
|
|
Guest_@Ark_*
|
Dec 13 2009, 19:14
|
Guests
|
Цитата Никакого ответственного оборудования (медицинского, промышленного) через такой порт делать нельзя. Вы не торопитесь с выводами. Мы, также, FTDI давно и успешно используем. Что-то не так в вашей схеме или программе. Чудес-то не бывает. 
|
|
|
|
|
|
|
|
Dec 13 2009, 19:37
|
Знающий
Группа: Свой
Сообщений: 580
Регистрация: 3-06-08
Пользователь №: 38 041
|
Цитата(@Ark @ Dec 13 2009, 22:14) Вы не торопитесь с выводами. Мы, также, FTDI давно и успешно используем. Что-то не так в вашей схеме или программе. Чудес-то не бывает. Бывает , бывает! Вот прогнал скорость 19200 без паритета - 1616 циклов без ошибок (вот уже 2180 без ошибок ). Значит FTDI не всегда удается передавать посылки с использованием паритета. А на 38400 и 9600 удается! Вот так вот. 0 не появляются, я гоняю сырые байты - MODBUS RTU, он очень критичен ко всему и если в канале какие затыки сразу вытрясает их. Пришлось, правда, практически до безобразия, расширить допустимый интервал между байтами на стороне компа, но это на маленьких пакетах никак не улучшило дело.
Сообщение отредактировал firstvald - Dec 13 2009, 19:44
|
|
|
|
|
|
|
Guest_@Ark_*
|
Dec 13 2009, 20:05
|
Guests
|
Цитата Бывает , бывает! Вот прогнал скорость 19200 без паритета - 1616 циклов без ошибок (вот уже 2180 без ошибок ). Значит FTDI не всегда удается передавать посылки с использованием паритета. А на 38400 и 9600 удается! Вот так вот Ну Вы даете. Так это проблемы использования MODBUS под Win, а не FTDI. Она передает и принимает все как надо. И, насколько мне известно, паритет она за Вас считать/проверять не будет - это должны делать передающие/принимающие модули. Могу только посоветовать установить бит паритета в 1 постоянно. Модбас такой режим допускает. Установить таймаут ожидания ответа порядка 100мс. А так как винда может, все равно, вставить паузу в непрерывный поток байтов при приеме/передаче - придется смириться с каким-то количеством ошибок и организовать повторные запросы.
|
|
|
|
|
|
|
|
Dec 14 2009, 08:28
|
Знающий
Группа: Свой
Сообщений: 580
Регистрация: 3-06-08
Пользователь №: 38 041
|
Цитата(@Ark @ Dec 13 2009, 23:05) Ну Вы даете. Так это проблемы использования MODBUS под Win, а не FTDI. Она передает и принимает все как надо. И, насколько мне известно, паритет она за Вас считать/проверять не будет - это должны делать передающие/принимающие модули. Могу только посоветовать установить бит паритета в 1 постоянно. Модбас такой режим допускает. Установить таймаут ожидания ответа порядка 100мс. А так как винда может, все равно, вставить паузу в непрерывный поток байтов при приеме/передаче - придется смириться с каким-то количеством ошибок и организовать повторные запросы. Нет не так. MODBUS под виндой спокойно работает во всем диапазоне скоростей. Правда, нужно очень аккуратно заполнять для каждой скорости структуру тайм аутов. И вовсе не теми числами, которые туда просятся теоретически  Дело тут не в MODBUS - он просто обнаруживает те ошибки , о которых, гоняя символьные посылки, можно было до пенсии и не подозревать. Паритет должен проскакивать через FTDI насквозь без изменения. Так, как его сформировал передатчик. И мы должны иметь возможность работать со всеми возможными сочетаниями параметров связи. Получается, что надо нащупать какие работают , а какие - с вопросами. Чтобы заказчику потом объяснить - ты сюда не ходи, снег башка попадет. С тайм аутами да, очень аккуратно надо их выставить. Но то , что работало во всех диапазонах скоростей через честный RS, должно работать и сейчас (возможно некоторые тайм ауты надо увеличить - расстояние между байтами, скорее всего - да). Иначе скандал - RS в каком-нибудь небуке не бывает , а в цеху надо посмотреть. Начинаем смотреть и выясняется, что все посмотреть то и нельзя! У меня уже несколько раз была мысль о большом компе на тележке  Персоналом, как бред не воспринимается. Про паузы. Непрерывные потоки не смотрел. На, скажем, в 256 байт, выходящих из машины, разрывов и пауз не видел ни разу. Этот вопрос я первым делом проверял. При приеме, уже написал, что если заполнить аккуратно структуру тайм аутов, каких - то провалов не наблюдается (но не на непрерывных данных). Но, это при значениях в структурах, которые сильно отличаются от того, что бы туда надо было прописать подсчитав карандашиком. Тайм ауты винда точно не считает. Вот интересно - окуда FTDI берет тактовые импульсы? ВМ их из кварца брала. А у этой? Буду еще смотреть.
|
|
|
|
|
|
|
Guest_@Ark_*
|
Dec 14 2009, 09:19
|
Guests
|
Цитата Нет не так. MODBUS под виндой спокойно работает во всем диапазоне скоростей. Правда, нужно очень аккуратно заполнять для каждой скорости структуру тайм аутов. И вовсе не теми числами, которые туда просятся теоретически. Дело тут не в MODBUS - он просто обнаруживает те ошибки , о которых, гоняя символьные посылки, можно было до пенсии и не подозревать... Что-то не то Вы пишите. FT232 вполне нормальная, надежная м/c. Кучу серийных устройств на ней реализовали. Не припомню что-то проблем, о которых Вы здесь говорите. Все нормально работает, на всех режимах и скоростях. Генератор у нее внутренний, внешний кварц не требуется. Этим она и привлекательна. В ДШ все описано... Межбайтовый и межфреймовый таймауты для MODBUS прописаны в самом протоколе, и устанавливать его по своему усмотрению - есть нарушение со всеми вытекающими... Так что, в первую очередь, ищите ошибки в своих программах и схемах, а не там где их нет.
|
|
|
|
|
|
|
|
Dec 14 2009, 09:32
|
тут может быть ваша реклама
Группа: Свой
Сообщений: 1 164
Регистрация: 15-03-06
Из: Санкт-Петербург/CA
Пользователь №: 15 280
|
Цитата(vetal @ Dec 13 2009, 22:06) Используем чипы и фирменные шнурки от FTDI на скоростях от 2400 до 750000(трафик от 20б/с до 100кб/с) - указанных симптомов не наблюдалось даже при прогоне 24/7. Ищите ошибки в своих программах. Настоятельно рекомендую посмотреть наличие 0x00 перед местами возникновения потенциальных потерь.( Как ни странно - весьма распространенная ошибка ) Цитата(@Ark @ Dec 13 2009, 22:14) Вы не торопитесь с выводами. Мы, также, FTDI давно и успешно используем. Что-то не так в вашей схеме или программе. Чудес-то не бывает. Согласен. Еще предложение. Возможно причина в несогласованносте скоростей UART у FTDI и в вашем МК из-за неточности частоты, тактирующей UART МК. На FTDI 19200 у вас 19100 например, как правило в доках на МК есть таблицы вероятности ошибок в зависимости от частоты и бодрэйта. Но там речь идет о единицах процентов в худшем случае.
|
|
|
|
|
|
|
Guest_@Ark_*
|
Dec 14 2009, 12:13
|
Guests
|
Цитата ... как правило в доках на МК есть таблицы вероятности ошибок в зависимости от частоты и бодрэйта. Но там речь идет о единицах процентов в худшем случае. Вполне вероятная причина. У внутреннего генератора FT232, также, возможно отклонение +/- 0,16% от номинала. Если скорости UART-тов не совпадут, примерно, на 2% или более - могут возникнуть ошибки... И еще. Автор пишет об ошибках только при передаче в компьютер. Возможно, фронты сигнала "завалены" на линии передатчика UART MK, по каким-то причинам. IMHO, нужно сначала проверять работу схемы, а не наводить статистику.
|
|
|
|
|
|
|
Guest_@Ark_*
|
Dec 14 2009, 12:54
|
Guests
|
Цитата Наиболее вероятно - отклонение генератора в микросхеме, но это только догадка.
Статистикой только и надо заниматься. Я вижу причины Вы не хотите искать. Ну тогда занимайтесь догадками и статистикой, составляйте "карту минных полей"... Удачи!
|
|
|
|
|
|
|
|
Dec 14 2009, 14:12
|
Знающий
Группа: Свой
Сообщений: 580
Регистрация: 3-06-08
Пользователь №: 38 041
|
Удалось обмен отладить - в структуре тайм-аутов тайм-ауты, начиная со скорости 19200 (хотя не понятно: для 38400 57600 115200 можно оставить то, что есть), пришлось увеличить в два раза по сравнению с теми значениями, при которых обмен работает нормально через обычный RS (замечу еще раз , что нормально обмен работает не при вычисленных значениях, а при подобранных, винда тайм-ауты считает практически никак, а менее 10 мс вообще никак).
Теоретически, на символьных посылках с большими тайм-аутами этой проблемы не заметно вообще. Поэтому у кого-то работало и он уверял , что проблемы нет. На самом деле, если предполагается, что железяка должна работать и через RS и через мост или сразу только через мост, нужно потренировать обмен и посмотреть как там дела.
В старых разработках, которые работали через RS, а теперь возможно будут работать через мост или в устройство вделывается мост и устройство становится как-бы USB, возможно, во внешнем софте придется подкорректировать константы в структурах тайм-аутов.
Чудеса с паритетом запишем пока в загадки, возможно немного времени не хватало, но это надо обдумать.
|
|
|
|
|
|
|
|
Dec 14 2009, 18:18
|
Знающий
Группа: Свой
Сообщений: 580
Регистрация: 3-06-08
Пользователь №: 38 041
|
Цитата(vetal @ Dec 14 2009, 17:43) Сдается мне, что вы наотрез не хотите смириться с тем, что вы работаете с контроллером шины USB, имеющем интерфейс UART, а не наоборот. Замирания 20-1000мс(и хуже) - совершенно нормальная ситуация при работе под управлением ОС семейства Windows Битовая скорость внешнего физического интерфейса(uart) и скорость обмена(что применимо и для задержек) информацией по шине USB имеют очень слабую связь, которая больше влияет на трафик, чем на задержки в отличие от наличия встроенного контроллера! Равно как и при работе с удаленным(сетевым) последовательным портом задержки могут доходить до нескольких секунд. Конечно не хочу мириться! Был RS232, можно было общаться с устройствами. А сейчас получается такая ситуация, что надежно общаться с устройством просто не через чего! Нету такой дырки в компьюторе! Одну засопливили, а новой не просверлили! Вернее просверлили, но не ту и не там. Спонтанные провалы на несколько секунд , полнейшее искажение временных соотношений между посылками при вставлении в последовательный канал сегмента локальной сети у нас коллеги видели, вернее, нарвались. Второй или даже третий год не знают чего делать. Поигрались (вдоволь ) тайм -аутами и, похоже, банально переспросами проблему закрыли.
|
|
|
|
|
|
|
|
Jan 30 2010, 13:22
|
Знающий
Группа: Свой
Сообщений: 841
Регистрация: 10-05-07
Из: Чебоксары (Россия)
Пользователь №: 27 640
|
Цитата(firstvald @ Dec 14 2009, 21:18) Спонтанные провалы на несколько секунд , полнейшее искажение временных соотношений между посылками... Не понял, вы не в курсе, что FTDI и прочие переходники USB -> COM данные через bulk передают? А если знаете, то почему считаете, что может быть по другому? Сделайте своё USB устройство и будет вам счастье. До 500 кбод вполне HID для этого подойдёт - драйверов не нужно будет.
|
|
|
|
|
|
|
|
Feb 1 2010, 11:41
|
Знающий
Группа: Свой
Сообщений: 841
Регистрация: 10-05-07
Из: Чебоксары (Россия)
Пользователь №: 27 640
|
Цитата(firstvald @ Feb 1 2010, 11:24) Да нет. Так нельзя. В мире уже сложилось что общение с приборами происходит по последовательным протоколам. Ряд из них требует довольно жестких временных соотношений при обмене. Попытки отказаться в компьюторах от обычного послеледовательного порта приводят к тому, что такой компьютор тут же превращается в Dendy, годное только на MP и Word. Спасать лицо компам пытаются через оставшиеся дырки : локльную сеть и USB. Не работает ни то ни то. 1. USB - это последовательный протокол. 2. Жёсткие времянки д.б. возложены на контроллер. 3. Появление USB в компе - наоборот прорыв на новый уровень. USB-шные флешки тому пример. Другое дело, что люди в силу своей костности этого не замечают или не хотят замечать. Или скрывают т.о. своё незнание/неумение. Я делаю свои девайсы подключающимися в USB как составное устройство HID+MassStorage. Это позволяет челу, который никогда не видел мой девайс и не знал о его существовании сразу начать с ним работать - воткнуть в USB и всё. При этом появится окошечко с файлами (MassStorage), среди которых будет pdf-ка с описанием, исполняемый файл (exe-шник) для работы с моим девайсом и лог-файл, в который мой девайс складывает данные при работе без компа. Запустив exe-шник можно просмотреть лог, настроить мой девайс (через HID), а при подключении к объекту поуправлять и пополучать данные в реалтайме. Всякие модбасы, CAN и т.п., где нужны времянки, естественно формируются в моём девайсе. При этом чела не заставили устанавливать никакие драйверы, не задали ему ни одного вопроса, не заставили выходить в инет, вводить коды активации и т.д. и т.п. И вообще у него не возникло никаких вопросов. Точнее возник только один - а почему другие так не делают? Цитата(firstvald @ Feb 1 2010, 11:24) То, как FTDI обменивается с компьютором должно быть абсолюно фиолетово, если смотреть на обмен со стороны API. А получается, что FTDI показывает в API свои заморочки. Это недоработка или небоежность FTDашного писателя. Если знаешь , что READFILE может вывалится потому что у тебя там что то не успело, но при этом сам обмен нормальный, нафига так писать? FTDI и т.п. переходники, на мой взгляд вообще не имеют права на жизнь. Ни одного преимущества у них нет. Та же FTDI вначале позиционировалась как временное решение. Но нет ничего более постоянного, чем временное...
|
|
|
|
|
|
|
|
Feb 1 2010, 12:46
|
Знающий
Группа: Свой
Сообщений: 841
Регистрация: 10-05-07
Из: Чебоксары (Россия)
Пользователь №: 27 640
|
Цитата(jorikdima @ Feb 1 2010, 15:30) Когда на МК нет ЮСБ или же обмен данными через ЮСБ настолько прост (малые объемы данных), что не хочется тратить время на реализацию ЮСБ в МК, а пользоваться UART, почему бы и нет???
Эти переходники довольно активно используютсявразличных приборах. МК с USB уже $3 стоят. Причём это АРМ от STM. При цене FTDI $2 (?) на МК $1 остаётся. Причём в этом случае будет 2 корпуса. Поэтому никакого смысла из-за экономии денег использовать МК без USB, при подключении к USB нет. Если уж так нравится, то можно эмулировать COM на МК с USB. Один раз сделал - и пусть кочует из проекта в проект... А то, что они активно используются, это не есть хорошо...
|
|
|
|
|
|
|
|
Mar 30 2010, 12:18
|
Участник
Группа: Участник
Сообщений: 23
Регистрация: 1-07-09
Пользователь №: 50 799
|
у меня работает связка на 1 мбит делиттель на FTDI принудительно на 3 Код ftStatus=FT_SetDivisor(ftHandle,3);
FT_SetTimeouts(ftHandle,1000,500);
FT_SetDataCharacteristics(ftHandle,FT_BITS_8,FT_STOP_BITS_1,FT_PARITY_NONE); ATMEGA8 _кварц _ 8MGZ обязательно от RC не рабоатла пакет аж 32768 байт Код ;ИНИЦИАЛИЗАЦИЯ UART
ldi temp,0
out UBRRL,temp;СКОРОСТЬ
clr temp
out UBRRH,temp;СКОРОСТЬ
ldi temp, (0<<U2X)
out UCSRA,temp
;Enable receiver and transmitter
ldi temp, (1<<RXEN)|(1<<TXEN)
out UCSRB,temp
;Set frame format: 8 data, 1 stop bit
ldi temp, (1<<URSEL)|(3<<UCSZ0)
out UCSRC,temp
--------------------
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
