AVR Раздел по микроконтроллерам компании Atmel - AVR / ATtiny / ATmega / ATMega128 / ATxmega, вопросы по программированию в AVR studio и все, относящееся к AVR... |
17.09.2019, 16:05
|
|
Гражданин KAZUS.RU
Регистрация: 16.06.2005
Сообщений: 945
Сказал спасибо: 25
Сказали Спасибо 175 раз(а) в 124 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Сообщение от AR_Favorit
|
Вывод - проблема точно не в том месте, которое определяет конец передачи последнего байта. Ибо проблема возникает еще до передачи предпоследнего. Когда до проверки, определяющей, не пора ли ронять ли PB4, еще целый байт слать.
|
Неа, проблема именно в этом месте - механизм возникновения я описал выше.
|
|
|
Сказали "Спасибо" Someone
|
|
|
17.09.2019, 16:20
|
|
Гражданин KAZUS.RU
Регистрация: 16.06.2005
Сообщений: 945
Сказал спасибо: 25
Сказали Спасибо 175 раз(а) в 124 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Т.е. в стиле написания кода топикстартера "слегка оптимизированная" версия кода выглядеть должно примерно так:
PHP код:
|
void RS485_U0_send(unsigned char *buff, unsigned char len) { PORTB |= (1 ‹‹ PB4);//and set high level
while (len) { UDR0 = *buff++; while(!( UCSR0A & (1 ‹‹ TXC0)));// UCSR0A |= (1 ‹‹ TXC0); len--; } PORTB &= ~(1 ‹‹ PB4);//set R/W low level inc_tranzaction_MB1(); }
|
т.е. пихаем байт в буфер и ждём ЗАВЕРШЕНИЯ ЕГО ПЕРЕДАЧИ. После чего уменьшается количество байт к передаче, проверяется условие выполнения тела цикла (нарушится когда len станет 0), и отключаем передатчик 485го - ведь ПЕРЕДАЧА последнего байта уже завершена.
Последний раз редактировалось Someone; 17.09.2019 в 16:31.
|
|
|
Сказали "Спасибо" Someone
|
|
|
17.09.2019, 16:24
|
|
Почётный гражданин KAZUS.RU
Регистрация: 08.10.2007
Сообщений: 2,760
Сказал спасибо: 1,105
Сказали Спасибо 1,037 раз(а) в 569 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Сообщение от индюк
|
прекращайте хреновней заниматься.
ставьте драйвер от каншины. там нет
|
Молодец, чо. Значит, пошёл одной дорогой, заблудился слегка - "плохая дорога!" давай по другой пойдём.
В кане граблей не будет?
|
|
|
|
17.09.2019, 22:01
|
|
Супер-модератор
Регистрация: 13.03.2004
Адрес: Minsk
Сообщений: 2,381
Сказал спасибо: 1,962
Сказали Спасибо 1,328 раз(а) в 578 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Сообщение от akegor
|
Очень уж должны сойтись звезды... Но тут поможет запрет переключения на прием при непустом регистре данных передачи.
|
Да никакого схождения звезд, все закономерно.
-пишем байт в UDR, он тут же перекидывается в сдвиговый регистр и начинает сдвигаться. Заметим - относительно медленно, по сравнению с программой...
-UDR свободен - пишем второй байт, он там и сидит, ждет своей очереди.
Тут программа решает, что всё, и только теперь (!!!) проверяет и потом сбрасывает TXC бит, а он установился еще после передачи первого байта. Ну и выключает PB4, хотя два байта еще не переданы.
__________________
[ жизнь приятна и красива, если выпить литр пива ]
|
|
|
|
18.09.2019, 12:07
|
|
Гражданин KAZUS.RU
Регистрация: 16.06.2005
Сообщений: 945
Сказал спасибо: 25
Сказали Спасибо 175 раз(а) в 124 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Сообщение от nml
|
а он установился еще после передачи первого байта.
|
Не-не-не, тогда бы прога работала бы неправильно ВСЕГДА. Флаг TXC, согласно даташита, устанавливается только если завершилась передача И ОДНОВРЕМЕННО с этим UDR пуст. Т.е. после завершения передачи первого байта, второй ожидает в буфере, перемещается в сдвиговый регистр, А ФЛАГ TXC НЕ СТАВИТСЯ - потому что в момент окончания передачи в удр данные есть. Потому у топик-стартера и работала, в основном, лишь иногда выдавая сбои, как он писал.
|
|
|
Сказали "Спасибо" Someone
|
|
|
18.09.2019, 14:18
|
|
Супер-модератор
Регистрация: 13.03.2004
Адрес: Minsk
Сообщений: 2,381
Сказал спасибо: 1,962
Сказали Спасибо 1,328 раз(а) в 578 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Сообщение от Someone
|
И ОДНОВРЕМЕННО с этим UDR пуст.
|
Да, вы правы, есть в даташите такое:
Код:
|
and there are no new data currently present in the transmit buffer (UDR). |
Действительно, странно тогда.
Когда-то помню сам делал подобное переключение направлений, но там был полудуплекс, то есть на Rx получал свое же передаваемое, и поскольку кадры и туда и сюда были стандартные, то как-бы "нехотя" принимал и свое же. Ну и переключение направления сделал по приему "своего". Ожидания при передаче .... некрасиво.
Кстати, вполне можно допустить и затык в каком-нибудь прерывании (для проверки запретить прерывания на время передачи), или элементарного плохого питания (развязывающие 0.1 uF между питательных ног добавить)
Я бы отладчиком отловил момент переключения направления и посмотрел все остальное... Короче, вариантов решения вагон, но ТС кажется уже отключился.
__________________
[ жизнь приятна и красива, если выпить литр пива ]
|
|
|
|
18.09.2019, 18:53
|
|
Частый гость
Регистрация: 19.05.2010
Сообщений: 27
Сказал спасибо: 76
Сказали Спасибо 8 раз(а) в 2 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Нет, смотрю.
Отладил на столе для первого канала передачу ответа на прерываниях, раскидал по трем установкам.
Если криков с самой "работящей" установки за пару смен не будет, переделаю и второй канал на прерывания.
И сам весь на "прерываниях", вчера за комп только после восьми часов работы сел, "туго" пошло, очевидную ошибку заметил только в метро.
|
|
|
|
18.09.2019, 19:15
|
|
Прописка
Регистрация: 27.05.2009
Сообщений: 180
Сказал спасибо: 250
Сказали Спасибо 113 раз(а) в 42 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Сообщение от nml
|
Ожидания при передаче .... некрасиво.
|
А чем так плохо ожидание, если не удастся отловить истинный момент окончания передачи? Если жалко тактов процессора, можно запустить таймер и переключить направление по прерыванию(не забыв отслеживать это при последующих передачах).
|
|
|
|
20.09.2019, 00:01
|
|
Почётный гражданин KAZUS.RU
Регистрация: 13.03.2010
Сообщений: 2,897
Сказал спасибо: 498
Сказали Спасибо 3,061 раз(а) в 1,425 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Сообщение от Someone
|
Неа, проблема именно в этом месте - механизм возникновения я описал выше.
|
Ваш диагноз - установка TXC0 во время цикла передачи из-за прерывания, не давшего подкинуть данные в буфер до истечения передачи уже находящегося в нем (задержавшего отправку на несколько сотен микросекунд, если я правильно посчитал) - выглядит точной причиной описанного поведения.
Только непонятно, почему в дальнейшем после первого возникновения эта ситуация постоянно повторяется, как сказано в первом посте, до сброса МК, ибо TXC0 перед выходом из процедуры передачи таки очищается...
Последний раз редактировалось AR_Favorit; 20.09.2019 в 00:15.
|
|
|
Сказали "Спасибо" AR_Favorit
|
|
|
21.09.2019, 12:02
|
|
Частый гость
Регистрация: 10.09.2010
Адрес: Резиновая
Сообщений: 45
Сказал спасибо: 3
Сказали Спасибо 14 раз(а) в 12 сообщении(ях)
|
Re: Странный баг управления драйвером RS-485
Сообщение от bdn62
|
..Отладил...
|
реализация алгоритма в модбасе влияет на помехозащищённость. статья лет дцать назад была на электрониксе вроде как(не нашёл, извиняйте).
основная мысль - не скидывать передачу сразу, а выжидать окончания слота + паузу переключения направления. тем самым линия всегда удерживается, что снижает вероятность ложной сработки.
т.е. после ухода всего буфера на передачу, взводиться тайм-аут и после его отрабтки линия отпускается. тайм-аут зависит от скорости, естественно.
|
|
|
|
Ваши права в разделе
|
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения
HTML код Выкл.
|
|
|
Часовой пояс GMT +4, время: 16:17.
|
|