И снова RS485, и снова проблемы, программное управление потоком Опции

[Axxel]

Всем доброго времени суток.

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

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

Собрал переходник 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;

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

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

Кстати: скорость 9600, длина 10м, помех нет, терминаторы не ставлю
из-за короткой линии (да и когда ставил проблемы были такие же)
т.е возможность проблемы с линией можно сразу отбросить.

Прикрепленные файлы

 rs485_rs232.pdf ( 15.4 килобайт ) Кол-во скачиваний: 143

 

[Andy Mozzhevilov]

Идти надо в сторону осциллографа и посмотреть на пинах драйвера, как ваш сигнал RTS соотносится с передаваемыми данными. Скорее всего вы убиратете RTS раньше, чем завершается передача пакета.

[Axxel]

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

То есть если я правильно понял, подобная проблема действительно имеет
(имела) место, или нет?

[Andy Mozzhevilov]

Да, я сам думаю про такое, но я видел примеры
программ, с тем же компонентом. Никаких задержек там не
ставится. Подразумевается что возврат из функции WriteStr
происходит после передачи всего пакета из UART

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

[upc2]

Вы не показали как МК подключается к линии.Может в этом и проблема?
А схему вашу я собирал .Работает хорошо.

[Axxel]

Вы не показали как МК подключается к линии.Может в этом и проблема?
А схему вашу я собирал .Работает хорошо.

МК подключен так:

Эскизы прикрепленных изображений

 

[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]

Какие страсти. Вы осциллограф то взяли в руки? Там же все сразу видно. Дел минут на 10.

Если закоротить вход и выход СОМ порта, то RTS на передачу никак не влияет.Значит причина в
драйвере Сом- порта.Здесь не нужен осциллограф.Или автор что-то не договаривает.

[Axxel]

Извините пожалуйста за долгие паузы, работа дерганая...
До осцилографа доберусь обязательно сегодня не смог, он у меня есть на работе.
В понедельник буду щупать
Спасибо вам за вашу помощь.

[rezident]

Типовых проблем при использовании RS-485 несколько. Я рекомендую соблюдать следующие правила.
Для мастера.
1. Пауза после переключения линии на передачу до непосредственно самого начала передачи. Нужна в RTU-ных протоколах для исключения порчи начала пакета из-за переключения прием/передача несогласованной линии.
2. Пауза с удержанием линии в состоянии передачи после окончания передачи. Опять же чтобы в RTU-ных протоколах не портился конец пакета.
3. Заранее определенный интервал времени для ожидания ответа от слейва. Чтобы не создавались коллизии в линии, когда мастер уже начал передачу нового запроса и слейв только еще начал передачу ответа на предыдущий запрос.
Для слейва.
Первые два как и для мастера, и кроме того еще
4. Пауза после получения получения пакета с запросом до начала передачи ответа. Опять же чтобы не создавать коллизию на линии, когда передача пакета закончена, но мастер еще удерживает драйвер в состоянии передачи.
5. Кроме того, если истек интервал времени, выделенный для подготовки ответа и начала передачи ответа, то слейв отвечать не имеет права. Причину см. в п.3.
В нормальных системах эти все паузы и интервалы имеют настраиваемые величины. Да, иногда и без некоторых из этих пауз работает, но если система построена так, как я описал, то работать будет всегда устойчиво.

[Axxel]

Всем доброго времени суток, и доброго понедельника!
Дорвался сегодня-таки до осцилографа, и первая стадия опытов показала:

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

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

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

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

Самое главное: Я могу при помощи осциллографа и задержек добиться
нормальной приемопередачи.
Но не пойму: это нормально? Так должно быть? Или же это косяк?