Реклама на сайте English version  DatasheetsDatasheets

KAZUS.RU - Электронный портал. Принципиальные схемы, Datasheets, Форум по электронике

Новости электроники Новости Литература, электронные книги Литература Документация, даташиты Документация Поиск даташитов (datasheets)Поиск PDF
  От производителей
Новости поставщиков
В мире электроники

  Сборник статей
Электронные книги
FAQ по электронике

  Datasheets
Поиск SMD
Он-лайн справочник

Принципиальные схемы Схемы Каталоги программ, сайтов Каталоги Общение, форум Общение Ваш аккаунтАккаунт
  Каталог схем
Избранные схемы
FAQ по электронике
  Программы
Каталог сайтов
Производители электроники
  Форумы по электронике
Удаленная работа
Помощь проекту

AVR Раздел по микроконтроллерам компании Atmel - AVR / ATtiny / ATmega / ATMega128 / ATxmega, вопросы по программированию в AVR studio и все, относящееся к AVR...

 
Опции темы
Непрочитано 17.09.2019, 16:05  
Someone
Гражданин KAZUS.RU
 
Регистрация: 16.06.2005
Сообщений: 859
Сказал спасибо: 26
Сказали Спасибо 157 раз(а) в 107 сообщении(ях)
Someone на пути к лучшему
По умолчанию Re: Странный баг управления драйвером RS-485

Сообщение от AR_Favorit Посмотреть сообщение
Вывод - проблема точно не в том месте, которое определяет конец передачи последнего байта. Ибо проблема возникает еще до передачи предпоследнего. Когда до проверки, определяющей, не пора ли ронять ли PB4, еще целый байт слать.
Неа, проблема именно в этом месте - механизм возникновения я описал выше.
Реклама:
Someone вне форума  
Сказали "Спасибо" Someone
Consum (21.09.2019)
Непрочитано 17.09.2019, 16:20  
Someone
Гражданин KAZUS.RU
 
Регистрация: 16.06.2005
Сообщений: 859
Сказал спасибо: 26
Сказали Спасибо 157 раз(а) в 107 сообщении(ях)
Someone на пути к лучшему
По умолчанию Re: Странный баг управления драйвером RS-485

Т.е. в стиле написания кода топикстартера "слегка оптимизированная" версия кода выглядеть должно примерно так:

PHP код:
void RS485_U0_send(unsigned char *buffunsigned char len)
{
    
PORTB |= (‹‹ PB4);//and set high level

    
while (len)
    {
        
UDR0 = *buff++;
        while(!( 
UCSR0A & (‹‹ TXC0)));//
        
UCSR0A |= (‹‹ TXC0);
        
len--;
    }
    
    
PORTB &= ~(‹‹ PB4);//set R/W low level
    
inc_tranzaction_MB1();

т.е. пихаем байт в буфер и ждём ЗАВЕРШЕНИЯ ЕГО ПЕРЕДАЧИ. После чего уменьшается количество байт к передаче, проверяется условие выполнения тела цикла (нарушится когда len станет 0), и отключаем передатчик 485го - ведь ПЕРЕДАЧА последнего байта уже завершена.

Последний раз редактировалось Someone; 17.09.2019 в 16:31.
Someone вне форума  
Сказали "Спасибо" Someone
nml (17.09.2019)
Непрочитано 17.09.2019, 16:24  
makakus
Почётный гражданин KAZUS.RU
 
Регистрация: 08.10.2007
Сообщений: 2,604
Сказал спасибо: 950
Сказали Спасибо 965 раз(а) в 518 сообщении(ях)
makakus на пути к лучшему
По умолчанию Re: Странный баг управления драйвером RS-485

Сообщение от индюк Посмотреть сообщение
прекращайте хреновней заниматься.
ставьте драйвер от каншины. там нет
Молодец, чо. Значит, пошёл одной дорогой, заблудился слегка - "плохая дорога!" давай по другой пойдём.
В кане граблей не будет?
makakus вне форума  
Непрочитано 17.09.2019, 22:01  
nml
Супер-модератор
 
Аватар для nml
 
Регистрация: 13.03.2004
Адрес: Minsk
Сообщений: 2,292
Сказал спасибо: 1,642
Сказали Спасибо 1,212 раз(а) в 542 сообщении(ях)
nml на пути к лучшему
По умолчанию Re: Странный баг управления драйвером RS-485

Сообщение от akegor Посмотреть сообщение
Очень уж должны сойтись звезды... Но тут поможет запрет переключения на прием при непустом регистре данных передачи.
Да никакого схождения звезд, все закономерно.
-пишем байт в UDR, он тут же перекидывается в сдвиговый регистр и начинает сдвигаться. Заметим - относительно медленно, по сравнению с программой...
-UDR свободен - пишем второй байт, он там и сидит, ждет своей очереди.

Тут программа решает, что всё, и только теперь (!!!) проверяет и потом сбрасывает TXC бит, а он установился еще после передачи первого байта. Ну и выключает PB4, хотя два байта еще не переданы.
__________________
[ жизнь приятна и красива, если выпить литр пива ]
nml вне форума  
Сказали "Спасибо" nml
Consum (21.09.2019)
Непрочитано 18.09.2019, 12:07  
Someone
Гражданин KAZUS.RU
 
Регистрация: 16.06.2005
Сообщений: 859
Сказал спасибо: 26
Сказали Спасибо 157 раз(а) в 107 сообщении(ях)
Someone на пути к лучшему
По умолчанию Re: Странный баг управления драйвером RS-485

Сообщение от nml Посмотреть сообщение
а он установился еще после передачи первого байта.
Не-не-не, тогда бы прога работала бы неправильно ВСЕГДА. Флаг TXC, согласно даташита, устанавливается только если завершилась передача И ОДНОВРЕМЕННО с этим UDR пуст. Т.е. после завершения передачи первого байта, второй ожидает в буфере, перемещается в сдвиговый регистр, А ФЛАГ TXC НЕ СТАВИТСЯ - потому что в момент окончания передачи в удр данные есть. Потому у топик-стартера и работала, в основном, лишь иногда выдавая сбои, как он писал.
Someone вне форума  
Сказали "Спасибо" Someone
bdn62 (18.09.2019)
Непрочитано 18.09.2019, 14:18  
nml
Супер-модератор
 
Аватар для nml
 
Регистрация: 13.03.2004
Адрес: Minsk
Сообщений: 2,292
Сказал спасибо: 1,642
Сказали Спасибо 1,212 раз(а) в 542 сообщении(ях)
nml на пути к лучшему
По умолчанию Re: Странный баг управления драйвером RS-485

Сообщение от Someone Посмотреть сообщение
И ОДНОВРЕМЕННО с этим UDR пуст.
Да, вы правы, есть в даташите такое:

Код:
and there are no new data currently present in the transmit buffer (UDR).
Действительно, странно тогда.

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

Кстати, вполне можно допустить и затык в каком-нибудь прерывании (для проверки запретить прерывания на время передачи), или элементарного плохого питания (развязывающие 0.1 uF между питательных ног добавить)

Я бы отладчиком отловил момент переключения направления и посмотрел все остальное... Короче, вариантов решения вагон, но ТС кажется уже отключился.
__________________
[ жизнь приятна и красива, если выпить литр пива ]
nml вне форума  
Сказали "Спасибо" nml
bdn62 (18.09.2019)
Непрочитано 18.09.2019, 18:53  
bdn62
Частый гость
 
Регистрация: 19.05.2010
Сообщений: 20
Сказал спасибо: 60
Сказали Спасибо 8 раз(а) в 2 сообщении(ях)
bdn62 на пути к лучшему
По умолчанию Re: Странный баг управления драйвером RS-485

Нет, смотрю.
Отладил на столе для первого канала передачу ответа на прерываниях, раскидал по трем установкам.
Если криков с самой "работящей" установки за пару смен не будет, переделаю и второй канал на прерывания.
И сам весь на "прерываниях", вчера за комп только после восьми часов работы сел, "туго" пошло, очевидную ошибку заметил только в метро.
bdn62 вне форума  
Непрочитано 18.09.2019, 19:15  
vit66work
Временная регистрация
 
Регистрация: 27.05.2009
Сообщений: 98
Сказал спасибо: 105
Сказали Спасибо 64 раз(а) в 26 сообщении(ях)
vit66work на пути к лучшему
По умолчанию Re: Странный баг управления драйвером RS-485

Сообщение от nml Посмотреть сообщение
Ожидания при передаче .... некрасиво.
А чем так плохо ожидание, если не удастся отловить истинный момент окончания передачи? Если жалко тактов процессора, можно запустить таймер и переключить направление по прерыванию(не забыв отслеживать это при последующих передачах).
vit66work вне форума  
Непрочитано 20.09.2019, 00:01  
AR_Favorit
Почётный гражданин KAZUS.RU
 
Регистрация: 13.03.2010
Сообщений: 2,886
Сказал спасибо: 490
Сказали Спасибо 3,035 раз(а) в 1,412 сообщении(ях)
AR_Favorit на пути к лучшему
По умолчанию Re: Странный баг управления драйвером RS-485

Сообщение от Someone Посмотреть сообщение
Неа, проблема именно в этом месте - механизм возникновения я описал выше.
Ваш диагноз - установка TXC0 во время цикла передачи из-за прерывания, не давшего подкинуть данные в буфер до истечения передачи уже находящегося в нем (задержавшего отправку на несколько сотен микросекунд, если я правильно посчитал) - выглядит точной причиной описанного поведения.

Только непонятно, почему в дальнейшем после первого возникновения эта ситуация постоянно повторяется, как сказано в первом посте, до сброса МК, ибо TXC0 перед выходом из процедуры передачи таки очищается...

Последний раз редактировалось AR_Favorit; 20.09.2019 в 00:15.
AR_Favorit вне форума  
Сказали "Спасибо" AR_Favorit
bdn62 (20.09.2019)
Непрочитано 21.09.2019, 12:02  
kolobok0
Частый гость
 
Регистрация: 10.09.2010
Адрес: Резиновая
Сообщений: 45
Сказал спасибо: 3
Сказали Спасибо 14 раз(а) в 12 сообщении(ях)
kolobok0 на пути к лучшему
Счастье Re: Странный баг управления драйвером RS-485

Сообщение от bdn62 Посмотреть сообщение
..Отладил...
реализация алгоритма в модбасе влияет на помехозащищённость. статья лет дцать назад была на электрониксе вроде как(не нашёл, извиняйте).

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

т.е. после ухода всего буфера на передачу, взводиться тайм-аут и после его отрабтки линия отпускается. тайм-аут зависит от скорости, естественно.
kolobok0 вне форума  
 

Закладки
Опции темы

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Книги (не радиотехнической тематики) Mike79 Делимся опытом 4248 31.03.2020 13:43
Ускорить компьютер 7Fantomas7 Ремонт оргтехники 111 08.08.2018 05:27


Часовой пояс GMT +4, время: 14:14.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd. Перевод: zCarot