Приемник UART работает независимо есть прерывание или нет, а вот если бы вмешался WDT, то программа уходит на restart преимущественно с начальными условиями. Но если инициализация переменных происходит при включении питания, то можно такую ситуацию незаметить...
Возможно здесь что-то другое но и это не исключено!?
А что автор молчит? Hey Daisy are you have any result of discussion???

А если имеет место помеха, как её отслеживать-улавливать-выявлять. Я и так уже сижу по часу у осциллографа в ожидании помех. :-)
Или это можно как-то программно сделать?

Имеется в вижу случай когда генератор сбивается. Как это отследить?

Приемник УАРТ работает как раз по прерыванию (внешний INT1). Он же у меня программный. А собака спит и не гавкает.
Вот засада. В следующий раз буду применять чипы с двумя уартами.

Да... у осцилографа часами сидеть бесполезно. Если подобным методом отслеживать помеху необходим программный хук и регистратор (осцилограф с паматью), таким образом после события отслеженного хуком (срабатывание на помеху, возможно ее анализ) необходимо останавливать регистрацию и тем самым информация о 'помехе' будет находиться в памяти регистратора (опять при условии, что время останова не превысит значение памяти регистратора). Но организовать все это не так-то просто!
Для начала я бы Вам посоветовал посмотреть уровень помех на земляной шине и питании (надеюсь Вы знаете, как это делается?). И в случае обнаружения 'иголок', если их амплитудное значение превышает порог логической '1' для AVR контроллера предпринять дополнительную фильтрацию или найти источник помехи и максимально снизить его.

А проверялся ли таким образом приемник? или он аппаратный?
Какое расстояние между микроконтроллерами участвующими в обмене? Используются ли преобразователи интерфейса?

А правильно настроены приемник и предатчик. У меня такое было когда я в одном указал на два стоп-бита а на другом на один стоп бит. Но все- таки надо конечно же контрольную сумму CRC8 или CRC16. Программки на асме есть где-то в нете

Вобщем дела такие.
Прошу прощение за столь долгое молчание. Наконец-то удалось дойти до (логического) конца. Эти УАРТ-ы меня выматали.
Когда оба УАРТ-а работали по прерываниям - ничего добиться не удалось.
Теперь аппаратный работает по опросу флагов, а программный по прерываниям. Помехи нет.
Только, это все такие была не помеха, а ошибка в программе. Но как она фильтровалась RC-цепочкой - загадка.
Большое спасибо всем за помощь.

Если не секрет, расскажите более подробно, что за ошибка? А то столько людей ломали голову, что бы Вам помочь. Да и вдальнейшем на такие грабли да бы не наступить...

А такой вопрос - в самом начале обработчика аппаратного UART-а стоит (стояло?) разрешение вложенных прерываний?
Быть может, просто длины этого обработчика хватало, чтобы иногда срубить времянку для программного?

Думаю, что вопрошающему надо почитать статейку =АК=, на сахаре, например. Потому как помогает ему RC-цепочка. А это симптом.
Вэлкомм:
http://www.caxapa.ru/faq/emc_immunity.html
ЗЫ. Цепочку, сто пудов надо ставить.

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

Видимо, когда первым вызывал прерывание аппаратный UART, прерывания запрещались, а вложенные не разрешались.
В результате со временем возникал конфликт и пропускалась (или откладывалась) обработка очередного фронта программного интерфейса.
Для AVR характерно, что входы и выходы внутренней аппаратуры стробируются тактовым генератором процессора.
Вот RC цепочка и сдвинула сигнал, смещая его из зоны конфликта.
Интересно, достаточно ли одинаковая скорость была у UARTов. Возможно, конфликта можно избежать, сделав эти скорости немного разными.

;О) ну насчёт того, что "знаем" не сумлеваюсь не разу, это раз. То, что Р-С цепь может лечить программный затык, надо записать где-нить, чтобы не забыть, это два. Просто холодильник за стенкой выключили на разморозку, и у человека слетать перестало.
А если серьёзно, то ситуаццыя такая - на нарастающем фронте INTn успевает сгенериться несколько прерываний(например, накладываются переходные процессы от нутряного тактирования), которые и могли калечить программную реализацию УАРТа многократным срабатыванием ИНТ. Р-С цепь убирала ВЧ составляющую и генерилось одно прерывание, всё, типа, путём. Такая ситуаццыя была особенно ярко выражена у АТ80Сх051. Там ИНТы находились вообще рядом с ОСЦ и наводка могла быть 100-200мв. Гы... кстати, у М128 аналогично. Так што Р-С, а точнее - С рулит. Думаю, пик 47-200 будет само то.

"Для AVR характерно, что входы и выходы внутренней аппаратуры стробируются тактовым генератором процессора.
Вот RC цепочка и сдвинула сигнал, смещая его из зоны конфликта"
Ну, дык, события-то асинхронные, сдвинули их на пол-того-туда-сюда, принципиально ничё не изменицца. ;О)