Ребят, уже 5 е сутки башкой об стену бьюсь...
немогу заставить нормально работать RS485 сетку...
--------
вообщем попорядку...
кристалл MEGA 64 AI
задействовано 2 уарт
USART0 - реализация протокола WAKE (master)
USART1 - реализация протокола ModBUS (slave)
собственно основная проблема c сетью на WAKE:
структура сети 1 мастер куча слейв...
на данный момент идет опрос только одного подчиненного.
непонятно по каким причинам программа вываливается в тайм аут
время "сбрыкивания" от 2 х сек до минуты
(но полюбому сбрыкивает)
(тайм аут выбран от 10 до 200 мС [100]) скорость сети 19200
сначала думал слейв не отвечает...
подцепил ко входам USART0 лог анализатор...
он показывает что во время возникновения тайм аута слейв всетаки ответил
и ответил корректно..
линия переключения RX-TX на драйвере 485 все ОК
сделал контроль регистр - рассовал вовсе точки.
и такое впечатление что на момент глюка приемник не принимает ни одного байта
почему? посылка идет 10-15 байт..
вот и не могу отследить где косяк
прерывания RXCIE, TXCIE и RXEN TXEN - всё включено постоянно...
осваиваю MKII недавно, может там есть какая нибудь функция которая поможет?

А зачем всегда прерывание по передаче стоит?
У меня
UCSR1B = _BV(RXCIE1) | _BV(RXEN1) | _BV(TXEN1);
в инициализации.

Сам использую кольцевой буфер. При записи в него активизируется прерывание, после опустошения - блокируется.
Еще вопрос: а нет конфликта по прерываниям, то есть их не много сыплется одновременно?

Попробуйте поставить точку прерывания в то место, где таймаут и запустите на выполнение. Можно наставить несколько аналогичных ловушек. У себя так программные ляпы отлавливал.

Да все это так...
все верно
так и сделано что в момент передачи приемник вообще отключается
а в момент приема - передотчик выкл
просто уже от бессилия все включил чтобы понять в чем дело
у меня так и тестится стоит бреакпоинт на таймауте
если снова запустить картина повторится чере 2.... 120 сек..
буфер кольца не к чему фрейм очень короткий и главное пока не рассмотрю принятый фрейм новый не передам.. (полудуплекс)
насчет конфликта по прерыванию
не исключено...
ну и пусть конфликт - тогда с большей вероятностью поднимется флаг FE или DOR
(хотя можно в этом направлении порыть)
чип тоже менял.... (менял и все устройство)

Может не переключается с передачи на приём? Поэтому и вся посылка теряется.

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

JTAG тут не сильно поможет. Не тот уровень. Можно цифровым осциллографом снять этот момент и проследить переключение направления.

А зачем его дергать?
TXC вызывается только когда символ полностью отправлен и по факту вызова прерывания сбрасывается.


Зачем это сделано?
Уберите вкл/откл приемника передатчика, держите их всегда включенными. Пролеты с включением/отключением добавляют повода для глюкавости. Управляйте только направлением драйвера и все должно быть Ок.


Как уже посоветовали - сделайте обработчики максимально возможно быстрыми.
Не анализируйте пакет в обработчике, зерно обработчика UART'a - байты. Rx должен вытянуть байт и куда-то его положить, просигналить что есть новые данные. Больше Rx обработчик ничего делать не должен.
Аналогично TXC обработчик должен взять байт и положить его в UART. Сменить направление драйвера на прием если брать больше нечего.

(не разрешайте прерываний в обработчиках прерываний).

спасибо за советы...
Прерывания никогда не разрешаю в прерываниях..
переключение передача прием тоже смотрел анализатором (цифровой осцилограф) все ок
обработчик максимально короткий (+ на ASM пишу).
Но с ещё большей уверенностью могу сказать что RX не генерит прерывание
завел контрольный регистр и прописал его сразу после команды чтения UDR
далее присваиваю ему значение скажем $DD сразу после оканчания передачи фрема в сеть.
и стою на бреак поинте...
после вываливания в тайм аут вижу как был $DD так и остался $dd
регистры UCSRb - без изменений...
ещё раз повторюсь осцилограф стоит на ногах (RX) - (TX) - (bus_rx-tx)...
все ок...
все посылает все отвечает...
Завтра тупо отключу все процедуры...

Брекпоинт можно поставить непосредственно в обработчике RX.


Приемник не выключали?
Не пишется ли в регистр управления этого UART'a из другого обработчика?
(проверьте не ошиблись ли банально с вектором прерывания, или с именами регистров).
Может дело в тайм-ауте - сильно короткий?

Проблема постоянная или возникает иногда?
Если проблема возникает иногда - попробуйте выделить событие-причину:
после какого события это происходит, напр. прием пакета другим каналом, n-й тик таймера, n-й пакет, n-й длины пакет и т.п.

МК2 ещё умеет ставить бряк по доступу в память и в область памяти. Можете посмотреть, кто пишет в регистры управления УАРТ или порт, определяющий направление передачи, если есть подозрение на косячество по управлению.

Приемник постоянно включен.
брекпоинт на обработчик - бессмыслено во первых нарушу динамику процесса, а во вторых постоянно будет вываливаться при "нормальном" приеме фрейма..
проблема постоянная хотя вылезает в достаточно короткое время(2 сек до 2 минут) и всегда!!
анализ события пока ни чего не дал.. очень хаотично возникает глюк
физика подключения все ок (на случай помехи то се - этого ничего нет)
даю картинки сего...
на левой показал что на RX идет фрейм без ошибок
на правой тайм аут беды ... принято без ошибок более 400 фремов

что касается времени самих прерываний...
RX int - меньше 60 тактов
TX - меньше 51 такта
(16 mHz clock)

распределение векторов:


да малостьввел в заблуждение..
скорость wake не 19200 а 50000
скорость модбас 19200

Так не в этом ли дело, что скорость нестандартная? Успеваете ли все прерывания обработать. Накопятся и стек рухнет.

А почему нет?
вакой я обслуживаю свои датчики с тойже скоростью
и потом 200 мкс/прерывание помоему это нормально..
и потом стек макс заполняется на 10-12 байт... за всю историю программы...

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

Я делаю не так, а как в Modbus. В смысле при приёме запускаю таймер выставленный на интервал чуть больше длит. одного байта. Таким образом если за это время поступает следующий байт, то таймер перезаряжается. Если байт не поступает, то именно это и является признаком конца посылки. Переключается на передачу и обрабатывается пакет. Ответ же поступает с задержкой. В связи с этим - никаких гонок нет.

Да я согласен на то что пусть даже режеться.....
но в момем случае ни одного байта не принимается при этом ни одной ошибки не выскакивает
типа FE, DOR, CRCerr - Просто тупо игнорирует весь фрейм...
---
но тут есть новости: отключение модуля TWI решает эту проблему...
покрайне мере устаешь ждать когда вылезет в таймаут...
буду копать пока в этом наравлении..
хотя выбрана невысокая скорость I2C = 47 кгц.
требования передавать данные для LCD 20Х4..

Боже а TWI здесь каким боком?
Если по прерыванию обрабатываете, то внимательно просмотрите.

Если после
.org TWIaddr ;= 0x0042
RJMP TWI_COMPLETE
идет код программы - то он затрет
.org UDRE1addr ;= 0x004e
rjmp TX_MODBUS

да не вектора правильно расположены..
это просто в коментарии опечатка...



Ребят, я отказываюсь понимать почему
но глюк был из за некоректной команды STOP в TWI..
я сам незнаю почему...
на некоторый момент линия SDA была после посылки в 0
единственая мысль это сверх частая генерация прерывания по TWI:
было

стало:

После чего проблему не наблюдаю уже 2й день...
Как это повлияло - загадка...

А.... Ну тогда я понимаю.

Здесь это уже обсуждалось на форуме.
Вроде бы при неправильной обработке TWI - наблюдаются зависалово.
Сам я с таким не сталкивался.
Поищи по форуму насчёт TWI.