Программный УАРТ работает на скорости 115200 в режиме приема. Обмен группами по 4 байта (от Cygnal к AVR), один раз в 700 мс.
Однако, где-то один раз в час проскакивает помеха. В результате один байт из 4-х неверен. Помеху можно убрать поставив RC-цепочку на линию передачи. Но ставить не хочется, ибо серия.
Какие есть варианты программной фильтрации? Или может быть ещё какие-то идеи?

Обычно на каждый бит делается три выборки и оценивается по мажоритарному принципу (чего больше, нулей или единиц).

Три делаю - не помогает. На большее число выборок времени не хватает.

Проверьте с аппаратным UARTом.
Если не поможет, то, видать, помеха уж очень длительная.

Помеха может быть всегда, идеального ничего не бывает... Наверное, тут и не в программном/аппаратном дело.
Я при обмене по USART всегда использую блок типа:
Служебный,N байт информации, контр.сумма
Вот это уже на порядок надежнее. Хотя и не 100% - как то пришлось передавать RS232 через радиомодули (махонькие такие, 433 МГц) - так вот при отсутствии сигнала с передатчика - по сути, приемник ловит белый шум - примерно раз в полминуты проскакивал прием посылки - то есть не только 4 байта подряд корректно ловились старты-стопы, но и контрольная сумма совпадала! Кстати, принималось на аппаратный USART.

Я был крайне удивлен сам... Хорошо что у тех радиомодулей была линия "есть сигнал" - иначе пришлось бы наверное усложнять суммирование...

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

Синхронизацию по старт биту делаете в программном усарте?

Да, по старт-биту. Принцип действия как в атмельском апноуте AVR304.

А поставить простенькую контрольную сумму есть возможность?

Только если в крайнем случае. За выдачу данных отвечает другой человек. Он против контрольных сумм. :-)
Перепишу программу на асме. Там должно влезть пять выборок на бит. Больше не знаю, что делать.

Попробуйте передавать вместо 4-х 5-байт, где первый из пяти является ключ-байтом передачи полезной информации. Тогда прием на помеху срабатывать не будет.

А Вы уверены что это именно помеха, а не сбой в передатчике, связанный хотя бы с нестабильностью частоты его герератора.

Да передачик вроде в порядке, во всяком случае на счет частоты. Данные с него заводились непосредственно на COM-порт компьютера. Никаких сбоев не наблюдалось. То есть компьютер эту помеху фильтрует.

Если помеха все-же имеет место возможно происходят сбои задающего генератора контроллера, которые естественно влекут за собой сбой в приемнике UART. Попробуйте проанализировать этот вариант. Если это так - панацею обсудим после.

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

Приемник 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 цепочка и сдвинула сигнал, смещая его из зоны конфликта"
Ну, дык, события-то асинхронные, сдвинули их на пол-того-туда-сюда, принципиально ничё не изменицца. ;О)

Если помеха проскакивает случайным образом и носит редкий характер, то достаточно передавать контрольную сумму и сравнивать ее на приемном конце. Если она не совпадает - повторить передачу. С Вашей вероятностью возникновения помехи, уверен, три раза повторять передачу не придется.

Попробую сейчас объяснить как это было.
Исходные данные:
*** at90s2313, 10МГц:
* с одной стороны принимает данные (4 байта ) по программному УАРТ-у от силабсового сигнала(48МГц) на скорости 115200. интервал посылок 700 мс.
* с другой стороны отвечает на однобайтовые запросы т.н. блока искробезопасного пятибайтными ответами по аппаратному УАРТ-у на скорости 2400. Интервал запросов 40 мс.

Сначала и то и другое работало по прерываниям. И случалась такая ситуация, что во время обработки прерывания от аппаратного уарт (2400), приходил старт бит байта (прерывание INT1) по программному УАРТ-у(115200).

Затем, отслеживая эту ситуация по флагам, приходилось терять посылку, не обращать на неё внимание.
И все равно порой что-то да проскакивало, за два часа раз. или за три.
Что-то видимо где-то недочищено было, флаг может быть какой-то взводился и не сбрасывался.

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

Про RC-цепочки надо почитать. ТОлько начальство не может и не хочет пойтить на аппаратные доработки, во всяком случае в этой партии.
Да и дело-то пока в программе оказалось.

И я о том же.
Отличная иллюстрация того, что у AVR на самом деле НЕТ приоритетной системы прерываний, которая, пусть в урезанном виде (без понятия приоритета процессора) есть у самого захудалого MCS51.

У меня старый-добрый АТ89С2051 выкидывал аналогичные кренделя и с приоритетными прерываниями. Нога ИНТ рядом с ОСЦ, чуть затянутый фронт и подкидон в критичной задаче тут как тут. Емкостишка на ногу рулит.

[/quote]
И я о том же.
Отличная иллюстрация того, что у AVR на самом деле НЕТ приоритетной системы прерываний, которая, пусть в урезанном виде (без понятия приоритета процессора) есть у самого захудалого MCS51.

[/quote]

Как понять НЕТ. Есть. и будет есть. Самый старший приоритет RESET. Затем внешние прерывания, UART где-то в конце. А если надо иначе - то разрешайте глобальное в обработчике прерывания. Лично пользовался и все работало.

[quote=&-rey,Sep 14 2005, 13:49]
[/quote]
И я о том же.
Отличная иллюстрация того, что у AVR на самом деле НЕТ приоритетной системы прерываний
[/quote]

Как понять НЕТ. Есть. и будет есть. Самый старший приоритет RESET. Затем внешние прерывания, UART где-то в конце. А если надо иначе - то разрешайте глобальное в обработчике прерывания. Лично пользовался и все работало.

[/quote]
Есть??? Ну извините.
Берём мегу128. Берём прерывание TIMER1CAPT. Прерывания от таймера 2 и внешние прерывания INT как бы имеют больший приоритет, а прерывания от остальных таймеров и UART как бы имеют меньший приоритет.
Пожалуйста, объясните мне, неразумному, как сделать такую вещь. Я хочу, чтобы обработчик TIMER1_CAPT было можно прервать любым внешним прерыванием или прерываниями таймера2, но нельзя прервать прерываниями от таймера3 и от USART-ов.
Если я в начале обработчика TIMER1_CAPT поставлю sei, то прерывание TIMER3_OVF, якобы самое низкоприоритетное, сможет прервать мой обработчик наравне с INT0. Ну и где тут приоритетная система???

У AVR НЕТУ приоритетной системы прерываний. Есть "близость к процессору в цепочке запросов", которая решает - кто из двух и более возьмёт управление при одновремённом возникновении запросов, такт в такт. И как часто это происходит? А если "более приоритетное" возникнет на такт позже "менее приоритетного"? А если при этом этом "менее приоритетное" ну очень не хочется прерывать "ещё менее приоритетным", так как "более приоритеное" выписано так, что быстро отработате и выставит флаги, а "ещё менее" может занять процессор на милисекунду, так как для фонового процесса это совсем до лампочки?

Итого я утверждаю, что слово "приоритет" применительно к прерываниям у AVR - это скорее маркетинговый термин, чем технический.

Когда такая система есть, то более приоритетное прерывание прервёт менее приоритетное как только более приоритетное возникнет - независимо от желания менее приоритетного. У MCS51 это возможно, более приоритетное может прервать менее приоритетное, менее приоритетное не будет вызвано пока более приоритетное не выполнит команду reti. Но у MCS51 нет понятия приоритета процессора и там нельзя "вот на этот период" запретить только менее приоритетные прерывания, а более приоритетные оставить.

===
MIPS - Meanless Indicator of Performance for Salesmen

"Итого я утверждаю, что слово "приоритет" применительно к прерываниям у AVR - это скорее маркетинговый термин, чем технический."
Дык, Атмел никогда не говорил про прерывания с приоритетом. Даже была инфа, что в какие-то АВРы только планируется её ставить.

"Я хочу, чтобы обработчик TIMER1_CAPT было можно прервать любым внешним прерыванием или прерываниями таймера2, но нельзя прервать прерываниями от таймера3 и от USART-ов.
Если я в начале обработчика TIMER1_CAPT поставлю sei, то прерывание TIMER3_OVF, якобы самое низкоприоритетное, сможет прервать мой обработчик наравне с INT0. Ну и где тут приоритетная система???"

Да, конечно если так ставить задачу, то нужно будет запрещать прерывания по соответствующим таймера3 и USART-ы. а по выходу разрешать их. Изврат ? - согласен. Но если нужно...

" У MCS51 это возможно, более приоритетное может прервать менее приоритетное, менее приоритетное не будет вызвано пока более приоритетное не выполнит команду reti. Но у MCS51 нет понятия приоритета процессора и там нельзя "вот на этот период" запретить только менее приоритетные прерывания, а более приоритетные оставить."
А, понял. У MCS51 можно разделить на 2 группы ? Конечно так довольно удобнее. Но ведь они все тратят 12 тактов на команду если Вы не имеете ввиду новые которые как и AVR восновном 1 тактные, но вроде это ядро называют 52 или нет? А с расчета разницы 12 тактов 51 и 1-го AVR разницы заметно не будет.

Т.е. атмел НЕ говорит о наличии приоритетной схемы прерываний (ибо их LSI-11 засмеяла бы), но слово "приортет" упоминает, так как звучит красиво.

Причём тут число тактов? Это параметр более технологический (что те же цигналы демонстрируют), чем архитектурный. Да и если в каждом прерывании сохранять состояние разрешения прерываний по менее приоритетным, а потом восстанавливать (так как, вообще говоря, может быть неизвестно, разрешены ли они в данный момент), то в терминологии времени заданного процессора (в машинных циклах, а не в тактах кварца) это будет слишком долго до разрешения прерываний более приоритетным и задача класса обсуждаемой выполнена всё равно не будет.

Ну и если время не сильно дваит (хотя необходимость в приоритетности прерываний возникает как раз тогда, когда оно давит ), то всё равно изврат и изврат именно потому, что приоритетной схемы у AVR просто нет.

"Т.е. атмел НЕ говорит о наличии приоритетной схемы прерываний (ибо их LSI-11 засмеяла бы), но слово "приортет" упоминает, так как звучит красиво"
Думаю, дело не в красоте. Надо-же как-то объяснить, что из N, одновременно случившихся событий исполнится одно по определённому правилу, и оставшиеся, аналогично.

В любом фирменном атмеловском описании на AVR расписана иерархия прерываний и она выполняется - железно. Можете сами проверить - запрограммировав прерывания по входу и подав на них один и тот-же импульсный сигнал. В теле каждого прерывания сделайте вывод в порт и посмотрите осцилографом, 'чья возьмет'...

"В любом фирменном атмеловском описании на AVR расписана иерархия прерываний и она выполняется - железно"

А что, кто-то говорит, что нет? Подымите мне веки. Но разделения по уровням приоритетов у АВРа нет.

О том и речь, что это не приоритетность в нормальном ее понимании.

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

Ну зачем я буду пересказывать посты RaAl своими словами. Там и так все разжевано до крайности. Доработать руками и сделать в AVR программно полноценную систему приоритетных прерываний невозможно. И интересно было бы выслушать, какие внешние навороты можно сделать для реализации нормальной приоритетности от внутренней периферии, скажем от UART и таймера? Ы?

PS. Меня вообще AVR слабо волнует, а вот в LPC2000 ARM-ах ихний VIC - практически один в один AVR по приоритетности, что обидно. Но там несколько другие причины, насколько я понимаю.
Для примера можно посмотреть, как по нормальному приоритетность реализована в Fujitsu MB90.