Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: И снова RS485, и снова проблемы
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам
Axxel
Всем доброго времени суток.

Я уже в принципе писал о своей проблеме в форуме
по микроконтроллерам, но проблема тогда возникала
из-за моих же неправильных действий unsure.gif

Сейчас проблема изменила свой "окрас", суть:

Собрал переходник RS232/RS485 по такой схеме (pdf внизу темы)
Программа в МК примерно следующая:"слушаем" линию-принимаем 20 символов-переходим в режим
передачи-передаем эти самые 20 символов обратно-"слушаем" линию.

На компе (пользуюсь компонентой COM library by Dejan Crnila):
все просто, взводим RTS-передаем-убираем RTS.
смысл кода таков:

RTS=1;
WriteStr(Str);
RTS=0;

происходят в данном случае глюки со следующими
симптомами:пакет передается то ли урезанный, то ли
с жуткими ошибками, но факт в том, что ожидаемый пакет
не отображается в окне терминала приема.После второй посылки
пакет приходит (т.е МК получает свои долгожданные 20 символов)
но естественно коряво.

Прикол также состоит в том что когда делаешь так:

RTS=1;
sleep(N msec);
WriteStr(Str);
sleep(N msec);
RTS=0;

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

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

Кстати: скорость 9600, длина 10м, помех нет, терминаторы не ставлю
из-за короткой линии (да и когда ставил проблемы были такие же)
т.е возможность проблемы с линией можно сразу отбросить.
Andy Mozzhevilov
Идти надо в сторону осциллографа и посмотреть на пинах драйвера, как ваш сигнал RTS соотносится с передаваемыми данными. Скорее всего вы убиратете RTS раньше, чем завершается передача пакета.
Axxel
Да, я сам думаю про такое, но я видел примеры
программ, с тем же компонентом. Никаких задержек там не
ставится. Подразумевается что возврат из функции WriteStr
происходит после передачи всего пакета из UART, т.е
по логике никакие задержки нам не нужны IMHO, никто не мешает
нам убирать RTS сразу после отправки пакета, IMHO опять же.
Хотя практика показывает совсем другое.
Такое я сам думаю может быть, хотя совсем нехотелось бы ругать
Винды, Гилла Бейтса и прочих уважаемых личностей из-за собственного
недопонимания.Осциллогорафом проверю.

То есть если я правильно понял, подобная проблема действительно имеет
(имела) место, или нет?
Andy Mozzhevilov
Цитата(Axxel @ Feb 16 2007, 10:26) *
Да, я сам думаю про такое, но я видел примеры
программ, с тем же компонентом. Никаких задержек там не
ставится. Подразумевается что возврат из функции WriteStr
происходит после передачи всего пакета из UART

Вот и проверьте скопом.
Выскажу предположение, что возврат может производиться после записи всех байт пакета в приемопередатчик (а он может и FIFO иметь). Практически уверен, что возврат не происходит именно по окончанию физической передачи всех битов последнего байта через UART, о чем косвенно свидетельствует то, что помогают задержки.
upc2
Вы не показали как МК подключается к линии.Может в этом и проблема?
А схему вашу я собирал .Работает хорошо.
Axxel
Цитата(upc2 @ Feb 16 2007, 11:01) *
Вы не показали как МК подключается к линии.Может в этом и проблема?
А схему вашу я собирал .Работает хорошо.


МК подключен так:
upc2
С интерфейсом все нормально. Думаю, что дело не в нем.
Драйверы ADM485 проблем обычно не создают.Они или работают ,или нет.
MAX232 можно проверить соединив ножки 11,10 , 9 послать и получить посылку в ПК.
Если посылка нормальная, то проблема с программированием МК.
Необходимо проверить ПО. Можно RxD и TxD МК непосредственно подать на вывода 11,10 и 9
МАХ232 и проверить без RTS. Т.к. всего 2 устройства , то это сработает.Если и это работает,
то необходимо проанализировать работу UART вашего МК.
Axxel
Когда ПК работает только на передачу(RTS всегда 1) или только на прием (RTS всегда 0)
обмен данными происходит нормально, проблема начинается с переключениями
Axxel
Да, и еще делал такой опыт:
соединял пины TxD и RxD на ПК, прямо на порте.
Делал посылку-глючит...
upc2
Похоже глючит МАХ202.Я использовал ADM232. 9600 - не проблема для порта ПК. а в МАХ202
что-то происходит.
Пока писал пришла новая информация.
Если Rx и Tx компьютера без МАХ, то драйвер СОМ порта.
Andy Mozzhevilov
Какие страсти. Вы осциллограф то взяли в руки? Там же все сразу видно. Дел минут на 10.
upc2
Цитата(Andy Mozzhevilov @ Feb 16 2007, 12:55) *
Какие страсти. Вы осциллограф то взяли в руки? Там же все сразу видно. Дел минут на 10.


Если закоротить вход и выход СОМ порта, то RTS на передачу никак не влияет.Значит причина в
драйвере Сом- порта.Здесь не нужен осциллограф.Или автор что-то не договаривает.
Axxel
Извините пожалуйста за долгие паузы, работа дерганая...
До осцилографа доберусь обязательно сегодня не смог, он у меня есть на работе.
В понедельник буду щупать smile.gif
Спасибо вам за вашу помощь. a14.gif
rezident
Типовых проблем при использовании RS-485 несколько. Я рекомендую соблюдать следующие правила.
Для мастера.
1. Пауза после переключения линии на передачу до непосредственно самого начала передачи. Нужна в RTU-ных протоколах для исключения порчи начала пакета из-за переключения прием/передача несогласованной линии.
2. Пауза с удержанием линии в состоянии передачи после окончания передачи. Опять же чтобы в RTU-ных протоколах не портился конец пакета.
3. Заранее определенный интервал времени для ожидания ответа от слейва. Чтобы не создавались коллизии в линии, когда мастер уже начал передачу нового запроса и слейв только еще начал передачу ответа на предыдущий запрос.
Для слейва.
Первые два как и для мастера, и кроме того еще
4. Пауза после получения получения пакета с запросом до начала передачи ответа. Опять же чтобы не создавать коллизию на линии, когда передача пакета закончена, но мастер еще удерживает драйвер в состоянии передачи.
5. Кроме того, если истек интервал времени, выделенный для подготовки ответа и начала передачи ответа, то слейв отвечать не имеет права. Причину см. в п.3.
В нормальных системах эти все паузы и интервалы имеют настраиваемые величины. Да, иногда и без некоторых из этих пауз работает, но если система построена так, как я описал, то работать будет всегда устойчиво.
Axxel
Всем доброго времени суток, и доброго понедельника! biggrin.gif
Дорвался сегодня-таки до осцилографа, и первая стадия опытов показала:

1)Если не делать задержку после вкл. RTS, то портится первый передаваемый
байт. (как и сказано выше rezidentом). Это видно по осцилографу: фронт RTS
совпадает с фронтом (даже можно сказать перекрывает) первого байта.

2)Если не делать задержку на отключение RTS после передаваемого пакета,
то тут еще не все потеряно. Интересно здесь то, что что пакет, в силу неизвестных мне
причин "гуляет" между фронтами RTS, и действительно, задержки, которые я устанавливаю,
помогают сделать так, чтоба пакет " не вышел" за пределы RTS.
Все это еще зависит от размера пакета, если пакет маленький (5-6 симв.)
то здесь у нас почему-то большая вероятность порчи. Опыты с маленькими
пакетами показывали даже то, что RTS уже отключен,а пара байт еще передается.

Тут, естественно, нужно отстраивать задержки в МК также.

"Гуляние пакета" между фронтами RTS мне кажется указывает на наличие
какого-то буфера.

Самое главное: Я могу при помощи осциллографа и задержек добиться
нормальной приемопередачи.
Но не пойму: это нормально? Так должно быть? Или же это косяк? cranky.gif
Andy Mozzhevilov
Винда не предназначена для таких выкрутасов. Это вам не реал-тайм. Возможно, где-то на уровне драйверов и можно это реализовать, но на уровне пользовательской программы, увы и ах...
Если это не серийное изделие, покрутите эти задержки и добейтесь нужного результата.
Axxel
>Если это не серийное изделие, покрутите эти задержки и добейтесь нужного результата.
Что же делать? wacko.gif

То есть получается что проще спаять переходник с автоматическим Flow controlем,
и не заморачиваться с RTS?
Вы например какие инструменты используете дабы избежать подобных проблем?

Устройство конечно же не серийное, изучаю для себя, но хотелось бы делать правильно.
upc2
1.Попробуйте заменить драйвер СОМ-порта. Если при закороченных Rx и Tx ПС переключение RTS
сбивает посылку, то такой драйвер вообще не годится.
2. Вместо RTS стандарт допускает использование одновибраторов для переключения
прием/передача. ..www.bb-elec.com
..http://www.bb-elec.com/tech_articles/rs422_485_app_note/overview.asp#rs485
Axxel
> Вместо RTS стандарт допускает использование одновибраторов для переключения

Адаптер с автоматическим управлением потоком?
Т.е все-таки проблема управления RTS-ом имеет место под Windows?
Или проблема все-таки в ДНК? biggrin.gif
И где взять "правильный" драйвер?
Просто программу проверял на 2-х разных компах- одна ерунда.

При использовании автоматического управления потоком проблема должна отпасть?
upc2
О появлении сигнала RTS сигнализирует CTS. Дождитесь этого сигнала, а потом отпавляйте
данные в буфер.Вы наверно упустили контроль этого сигнала.
Axxel
Цитата(upc2 @ Feb 19 2007, 13:36) *
О появлении сигнала RTS сигнализирует CTS. Дождитесь этого сигнала, а потом отпавляйте
данные в буфер.Вы наверно упустили контроль этого сигнала.

То есть? blink.gif
upc2
Появление сигнала RTS занимает много времени . Данные начинают идти, а передача еще закрыта.
Теряется стартовый бит и сбиваются посылки.По схеме RTS и CTS соединены.По появлению CTS
можно начинать передачу.Ну в контроллере необходима задержка.
Axxel
Цитата(upc2 @ Feb 19 2007, 13:51) *
Появление сигнала RTS занимает много времени . Данные начинают идти, а передача еще закрыта.
Теряется стартовый бит и сбиваются посылки.По схеме RTS и CTS соединены.По появлению CTS
можно начинать передачу.Ну в контроллере необходима задержка.


Да, должен сказать что упустил этот момент, даже в том
плане, что не использовал CTS из-за отсутствия необходимого
пина в разъеме от мыши (часть адаптера). Но на данный момент вроде
все это пока решается задержкой перед отправкой пакета.
А по какому событию можно определить конец посылки?
upc2
Разные программы бывают. Если не влезать в регистры UART, то когда передающий буфер пуст.
Axxel
Цитата(upc2 @ Feb 19 2007, 14:02) *
Разные программы бывают. Если не влезать в регистры UART, то когда передающий буфер пуст.

Да, нашел такое событие, переделал малость программку, но задержку
в обработчике события 5 мс перед отключением оставил, если не делать-виснет.
cioma
Как уже говорил Andy Mozzhevilov, Винда для такого не предназначена.
У нас была такая же необходимость в переходнике 232-485. Железо сделали как у Вас (простое решение по-другому и не сделаешь). А потом началя секс с программерам и задержками сигнала RTS. Ну не позволяет винда детерминированно управлять RTS относительно потока данных. Ставили девайс на прогон с подключенным осциллом (с infinit отображением сигналов), так иногда выскакивали дикие задержки с установкой, снятием RTS. Между Вами и реальным UART - куча программных прослоек, управлять которыми во времени нет возможности. Выход из этого - ваять полноценный преобразователь например на микроконтроллере: вход - RS-232, выход - RS-485.
muravei
Цитата(cioma @ Mar 8 2007, 13:37) *
Выход из этого - ваять полноценный преобразователь например на микроконтроллере: вход - RS-232, выход - RS-485.

Сделайте , по типу:
http://electronix.ru/forum/index.php?act=A...ost&id=9396
и не надо никаких микроконтроллеров.
wangan
Мне кажется кривизна в самой программе, как насчет вместо паузы использовать ожидания события ключивое слово OVERLAPPED. Еслиб посылка бы работала по возврату при постоянной передачи винда бы висла колом.
Axxel
Сделал преобразователь с автоматическим управлением потоком, простенький.
Вроде все стало нормально работать, RTS больше не использую.
smile.gif Пока все ОК, но думаю что вернусь еще к этому делу.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.