AVR и помехозащищенность

melandr

Добрый день, уважаемые коты! Хотелось бы услышать ваше мнение по поводу помехозащищенности микроконтроллеров AVR. Объясню в чем проблема. Есть такая отладочная плата Мк2313, описание во вложенных файлах. На основе этой платы был реализован контроллер управления гелиосистемой. Были подключены четыре датчика DS18B20. Циркуляционные насосы были подключены через 4-х канальный модуль реле Ардуино 5 В. Питание для модуля реле было взято с платы Мк2313. При эксплуатации были замечены следующие проблемы:
1. Иногда один или несколько датчиков температуры подвисали. Так как памяти не хватало для полноценного поиска датчиков, то адреса используемых датчиков заносились в флеш память и при старте контроллера выгружались в оперативную память. Периодически, если проверялось, что crc неправильный, то показания температуры не выводились. Пока не перегрузишь контроллер. Чаще такое наблюдалось при отключении насоса. Сам контроллер продолжал работать.
2. Иногда подвисал сам контроллер ATtiny2313. Такое происходило спонтанно без всякой системы. А также подвисал когда работали сваркой.
Сначала датчики были подключены витой парой, потом витую пару заменили на двухжильный провод в экране и проложили отдельно от силовых проводов. Датчики стали подвисать меньше. Но контроллер все равно подвисает. Теперь мысли, чтобы избавиться от этих проблем:
1. Необходимо использовать отдельный блок питания для запитки модуля реле. возникает вопрос, нужно ли землю блока питания контроллера соединять с землей блока питания модуля реле?
2. Блок питания самого контроллера реализован посредством трансформаторного блока на 12 В. На плату подается 12 В постоянного напряжения. На плате собран импульсный блок питания на МС33063, выдающий 5 В для питания контроллера.
Исходя из опыта эксплуатации промышленных контроллеров с питанием переменкой 24 В у них никаких проблем с зависаниями не возникало. Может кто-то подскажет, как можно сделать работу контроллера более надежной. До этого пытался делать таймер с такой же схемой питания и тоже были проблемы со стабильностью. При отключении пускателя происходило подвисание контроллера.
Заранее всем спасибо за конструктивную помощь.

Реклама

oleg110592

Посмотрите схему PLC, которым китайцы вовсю барыжат http://ru.aliexpress.com/item/20MR-20MT ... 04444.html
схему тут раздавали: http://radiokot.ru/forum/viewtopic.php?f=59&t=128469
МС33063, насколько помню, легко пропускала помехи по питанию - проблема решена была так: 24V->МС33063->12V->7805->5V плюс хорошая фильтрация питания ну важна правильная разводка платы.
DS18B20 имхо не лучший выбор для индустриальных применений - после включения/выключения пускателей и пр. необходима пауза (~100ms) перед запуском преобразования.

Реклама

BOB51

Совмещенный контроллер динамического дисплея, клавиатуры и 4 канала DS18B20?
Да еще на какой-нить "встроенной ОС" при использовании at90s2313?
Весьма смело...

melandr

На этой плате отлаживается работа солнечного коллектора. Никто не собирается его использовать постоянно, Просто не нужно было ничего изготавливать, а необходимо было подключить и проверять работу и какие вылезут огрехи.
ЗЫ:BOB51, а вы я смотрю только критиковать можете, и это уже не в первой теме, которые я создавал. А что то умное сказать мозга не хватает. Я создал это тему не для того что бы вашу критику выслушивать. Если ничего умного сказать не можете, МОЛЧИТЕ!!!. Меня ваши дебильные замечания не интересуют. Тем более если вы не в теме.
ЗЫ1:oleg110592, спасибо, буду разбираться. Все таки есть еще нормальные люди, которые готовы подсказать и помочь.

oleg110592 писал(а): DS18B20 имхо не лучший выбор для индустриальных применений - после включения/выключения пускателей и пр. необходима пауза (~100ms) перед запуском преобразования.

В принципе на более мощном камне рассчитываю делать программную обработку. Просто цена термосопротивления PT1000 - 300 грн, а ds18b20 в защищенном корпусе - 60 грн. Потому решили применить более дешевые датчики. А датчиков должно быть 6 штук. А применение будет не индустриальное, а домашнее. Хотя скажу честно вот продают терморегулятор ТК-4. Я лично его применял для управления работой вентилятора в курятнике по температуре - уже 2 года работает, и слава богу не жаловались. Там используется датчик ds18b20
oleg110592, также еще использовал МС34063 и трансформатор 24В. Почему то плата вышла из строя. Здесь на форуме мне ответили, что хоть по даташите МС34063 держит 40 В, но уже по переменке 24В. имеет по постоянке 33В. Может выйти из строя микросхема... Вот и думай теперь. Кстати как в этом плане LM2596? получше?

Реклама

oleg110592

melandr писал(а):цена термосопротивления PT1000 - 300 грн, а ds18b20 в защищенном корпусе - 60 грн.

Использую вместо DS иногда терморезистор NTC B57164K0103J000 (7,75 грн. жлобский Космодром), корпус не проблема (типа в корпус от маленького электролита залить), иногда и термоусадки хватает, табличка для преобразования в pdf нормальная есть, калибровки по одной точке достаточно, реагирует на температуру мгновенно (можно пид нормальный запилить), на 10-ти битном АЦП в принципе 0.1С можно получить (не во всем диапазоне), правда для пускателя 0.1C и не надо. АЦП в тини2313 нету, рекомендую, если авр, на мегу48 перейти - всяко получше и дешевле будет.
з.ы. МС34063 древнючая, сейчас есть микросхемы на мегагерцах и гигагерцах работающие - дроссель получается маленький

Реклама

pavel123

Тут же на радиокоте нашел вот такое ПДФ
Может пригодиться.

Реклама

shads

BOB51 писал(а):Совмещенный контроллер динамического дисплея, клавиатуры и 4 канала DS18B20?
Да еще на какой-нить "встроенной ОС" при использовании at90s2313?
Весьма смело...

А что смелого... обычное дело... еще даже остаются мощности... никакой ОС кстати не нужно...
Я такое как то тоже делал... http://asis-kbr.ru/forum/viewtopic.php?f=11&t=117
Правда у меня на Tiny26... но это сути не меняет, это в принципе та же 2313...

ARV · Сообщение **ARV** » Ср июн 22, 2016 07:17:05

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

приводить в пример устойчиво работающую в аналогичных условиях совершенно другую конструкцию на совершенно других комплектующих я прокомментирую таким примером

Спойлер

глядя на тонущую в огромной луже на проселке хонду, местный житель Петрович задумчиво говорит водителю: "хм... а я на своей ласточке тут пролетаю даже не вздрогнув...". только водитель хонды не в курсе, что Петрович "летает" на К-700...

в общем, при сбоях следует обратить внимание на:
- качество источников питания
- качество применяемых компонентов, особенно конденсаторов
- корректность схем питания (напр. соблюдение рекомендаций по применению стабилизаторов типа LM78xx)
- корректность схем (соблюдение рекомендаций) запуска и т.п. для МК и других цифровых компонентов (напр. цепи сброса, запуска генератора, подтяжки выводов и т.п.)
- наличие рекомендованных блокировочных конденсаторов вблизи выводов питания цифровых микросхем
- корректную разводку цепей питания, исключающую протекание силовых токов от нагрузок по тем же участкам, где протекают токи питания микроконтроллера или иных "слаботочных" элементов
- экранировку конструкции
- схемотехнику силовых ключевых элементов (напр., наличие снабберных цепей)
- наличие защитных цепей для внешних сигналов (напр., гальваническая развязка входов и выходов)
- наличие емкостей, обеспечивающих "стекание" импульсных токов в "землю"
- в программно-управляемых устройствах следует так же обратить внимание на алгоритм работы, который должен предусматривать самовосстанавливаемость исполнения программы при случайных сбоях, повреждении хранимых данных и/или при поступлении некорректных сигналов на входы.

ну и скажите, что из перечисленного вы не знали? уверен, что все это общеизвестно...

melandr

ARV, я с Вами полностью согласен. По поводу пунктов возможно не все, но многие пункты знаю. Правда не знаю как должно быть правильно. Потому и задал вопрос на форуме, чтобы учесть все эти нюансы при разработке собственной платы управления. Например, я считал ИИП на МС34063 работает, выдает нужное напряжение и какие могут быть проблемы. Но оказалось, что он плохо фильтрует помехи из сети. Поэтому реально ли использовать МС34063 в блоке питания микроконтроллерного устройства, добавив, допустим, фильтрующие элементы, как то синфазный дроссель, конденсаторы Х1. Или нужно применить принципиально другой ИИП на другой элементной базе. Сейчас допустим, решил, чтобы исключить помехи из сети вместо трансформаторного блока питания на 12В, применить автомобильный аккумулятор. Я так понимаю это должно отсечь помехи от сети. В данным момент при эксплуатации этой платы происходит порядка 4-5 зависаний контроллера в день. Используя эту плату, хочется определить все слабые места, и в дальнейшем при проектировании учесть эти моменты.Просто эксплуатируя промышленные контроллеры, я не наблюдал зависаний. Но как в этих контроллерах реализовано схемотехническое решение я не знаю. Потому и хочу путем ошибок и опытов сделать нормально действующее устройство. Опять же вопрос по поводу подключения модуля 4-х реле ардуино. Необходимо ли для него отдельное питание?
ЗЫ: Кстати насчет самовосстанавливаемости программы. Использовал watchdog в AVR. Но почему то не заметил, что он сбрасывает программу при зависании контроллера. Знакомый посоветовал использовать для сброса микроконтроллера внешнюю схему, например супервизор MAX705. Действительно ли оправдан такой подход? Или я неправильно использовал Watchdog.
ЗЫ1: Вот схемка используемого на отладочной плате ИИП. Что неправильно?

BOB51

У АВРок вполне достаточно собственных встроенных средств аварийного перезапуска для "типовых приложений".
Ежли уж "оченно хоцца" прицепить несколько датчиков uLAN протокола и иметь стабильно светящий дисплейчик прийдется почитать вот это:

AN214.pdf: (148.89 КБ) 321 скачивание

AN244.PDF: (222.94 КБ) 225 скачиваний

и вешать чем-то коммутируемые датчики (или программно-выбираемые) на аппаратный UART.
Касательно "сбоящих реле"... Для нормальной схемотехники и программного обеспечения - такие "дефекты" абсолютно исключены.

melandr

BOB51, проблема сейчас не в датчиках. То есть при отваливании датчика, программно можно несколько раз опросить и когда результат будет однозначен, тогда делать какие-то действия. Сейчас есть проблема периодического зависания контроллера.А по поводу встроенного watchdoga. Вот код, что неправильно, почему он не сбрасывал контроллер при зависании?

Спойлер

#define F_CPU 14745600UL
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>
#include <util/delay.h>
#include <avr/pgmspace.h>
#include "onewire.h"
#include "ds18b20.h"
#include "7seg.h"

#define PORT_OUTPUT PORTD
#define DDR_OUTPUT DDRD
#define PUMP_1 PD0
#define PUMP_2 PD1
#define PUMP_3 PD2
#define SIRENA PD3

#define SETBIT(x,y) (x |= (y)) // установка бита y в байте x
#define CLEARBIT(x,y) (x &= (~y)) // сброс бита y в байте x
#define CHECKBIT(x,y) (x & (y)) // проверка бита y в байте x
// Определяем маску-константу бита статуса
#define PUMP1_ON 0x01 // разряд 0 : Флаг работы насоса коллектора 1
#define PUMP2_ON 0x02 // разряд 1 : Флаг работы насоса коллектора 2
#define PUMP3_ON 0x04 // разряд 2 : Флаг работы насоса отопления
#define SIRENA_ON 0x08 // разряд 3 : Флаг звуковой сигнализации

//дефайны задержек времени
#define T_1SEC 1000
/*значение для счетного регистра*/
#define T_POLL 198 //Fcpu = 14.7456 IAo, k = 256,
//Tt0 = 256/14745600=0.0174 in, n = 1/0.0174=58
//T_POLL = 256 - 58 = 198

// Массив значений для индикатора
const char SEGMENTE[] PROGMEM = { //массив для перевода чисел в код понятный для индикатора
0x3F, // 0
0x06, // 1
0x5B, // 2
0x4F, // 3
0x66, // 4
0x6D, // 5
0x7D, // 6
0x07, // 7
0x7F, // 8
0x6F, // 9
0x40, // -
0x63, // знак градуса
0x00, // " "
0x5E // d
};

unsigned char ds18b20_devices = 4; // количество сенсоров в оперативной памяти
unsigned char owDevicesIDs[MAXDEVICES][8]; // Их ID
unsigned int temperature [4] = {0,0,0,0};
unsigned char error_crc[4] = {0,0,0,0};
static unsigned char znak[4]; //если 0 - плюс, 1 - минус

unsigned char DS18B20_rom[MAXDEVICES][8] PROGMEM = {
{0x28,0xFF,0xFE,0x3F,0x54,0x15,0x03,0x8A},
{0x28,0xFF,0xE5,0xC6,0x62,0x15,0x02,0x35},
{0x28,0xFF,0xA9,0x41,0x54,0x15,0x03,0xF3},
{0x28,0xFF,0xDB,0xC6,0x62,0x15,0x01,0xF1}
};

//Функция чтения rom датчиков из памяти программ в оперативную память
void ReadID(void)
{
int i,j;
for(i = 0; i < MAXDEVICES; i++)
for(j = 0; j < 8; j++)
{
owDevicesIDs[j] = pgm_read_byte(&(DS18B20_rom[j]));
}
}

//функция настройки таймера Т0
void Timer_init(void)
{
TCNT0 = T_POLL; //установка начального значения TCNT0
TIFR |= (1 << TOV0); //сброс флагов в регистре TIFR
TIMSK |= (1 << TOIE0); //разрешение прерывания по переполнению в TIMSK
TCCR0B |= (1 << CS02) | (0 << CS01) | (0 << CS00); //установка предделителя в TCCR0 (делитель 256)
}

// обработчик прерывания по переполнению Т0
ISR(TIMER0_OVF_vect)
{
static uint16_t cnt1sec = 0; //счетчик одной секунды
//перезапись счетного регистра
TCNT0 = T_POLL;

//сбрасываем сторожевой таймер
wdt_reset();

if (cnt1sec == 1000)
{
// fDebug = 1;
PORTB ^= (1 << PB4);
cnt1sec = 0;
}
cnt1sec++;
}

int main(void)
{
wdt_enable(WDTO_2S);
char flag = 0; // Объявляем байт статуса
Timer_init(); // инициализация таймера Т0

DDRB = 0b11010000; //Пины 6,7 - на вывод.
DATA_PORT = 0xFF; //все выводы 0
//настраиваем выводы для управления насосами и звуковым сигналом
DDR_OUTPUT |= (1 << PUMP_1)|(1 << PUMP_2)|(1 << PUMP_3)|(1 << SIRENA);
PORT_OUTPUT |= (1 << PUMP_1)|(1 << PUMP_2)|(1 << PUMP_3)|(1 << SIRENA);

ReadID();
/*
write_byte(pgm_read_byte(&SEGMENTE[ds18b20_devices])); // Выводим 3 разряд
write_byte(pgm_read_byte(&SEGMENTE[10])); // Выводим 2 разряд
write_byte(pgm_read_byte(&SEGMENTE[13])); // Выводим 1 разряд
_delay_ms(1000);*/

sei();
while(1)
{
if (ds18b20_devices > 0) //если датчики подключены производим опрос
{
DS18B20_StartMeasure(0); // запускаем измерение для всех датчиков
_delay_ms(750); // ждем минимум 750 мс, пока конвертируется температура
for (unsigned char i=0; i<ds18b20_devices; i++) // теперь сортируем устройства и запрашиваем данные
{
unsigned char data[2]; // переменная для хранения старшего и младшего байта данных
cli();
error_crc = DS18B20_ReadData(owDevicesIDs, data); // считываем данные
temperature = DS18B20_ConvertToThemperature(data,&znak); // преобразовываем температуру в человекопонятный вид
sei();
}
}
for (unsigned char i=0; i<ds18b20_devices; i++)
{
write_byte(pgm_read_byte(&SEGMENTE[10])); // Выводим "-"
write_byte(pgm_read_byte(&SEGMENTE[i+1])); // Выводим номер датчика
write_byte(pgm_read_byte(&SEGMENTE[10])); // Выводим "-"
_delay_ms(1000);
if(error_crc)
{
if (znak == 0)
{
write_byte(pgm_read_byte(&SEGMENTE[temperature%10])); // Выводим 3 разряд
write_byte((pgm_read_byte(&SEGMENTE[temperature%100/10]))|0x80); // Выводим 2 разряд
write_byte(pgm_read_byte(&SEGMENTE[temperature[i]%1000/100])); // Выводим 1 разряд
}
if (znak[i] == 1)
{
write_byte(pgm_read_byte(&SEGMENTE[temperature[i]%10])); // Выводим 3 разряд
write_byte((pgm_read_byte(&SEGMENTE[temperature[i]%100/10]))|0x80); // Выводим 2 разряд
write_byte(pgm_read_byte(&SEGMENTE[10])); // Выводим 1 разряд
}
}
else
{
write_byte(pgm_read_byte(&SEGMENTE[10])); // Выводим "-"
write_byte(pgm_read_byte(&SEGMENTE[10])); // Выводим номер датчика
write_byte(pgm_read_byte(&SEGMENTE[10])); // Выводим "-"
}
_delay_ms(2000);
}
//Если темп. коллектора 1 больше темп. низа бака на 10 град и насос выключен - включаем насос
if (temperature[0]>(temperature[2]+100) && !(CHECKBIT(flag, PUMP1_ON)) && error_crc[0] && error_crc[2])
{
PORT_OUTPUT &= ~(1<<PUMP_1);
SETBIT(flag, PUMP1_ON);
}
//Если темп. коллектора 1 больше темп. низа бака на 8 град.Ц и насос включен - выключаем насос
if (temperature[0]<=(temperature[2]+80) && CHECKBIT(flag, PUMP1_ON))
{
PORT_OUTPUT |= (1<<PUMP_1);
CLEARBIT(flag, PUMP1_ON);
}

//Если темп. коллектора 2 больше темп. низа бака на 10 град и насос выключен - включаем насос
if (temperature[1]>(temperature[2]+100) && !(CHECKBIT(flag, PUMP2_ON)) && error_crc[1] && error_crc[2])
{
PORT_OUTPUT &= ~(1<<PUMP_2);
SETBIT(flag, PUMP2_ON);
}
//Если темп. коллектора 2 больше темп. низа бака на 8 град.Ц и насос включен - выключаем насос
if (temperature[1]<=(temperature[2]+80) && CHECKBIT(flag, PUMP2_ON))
{
PORT_OUTPUT |= (1<<PUMP_2);
CLEARBIT(flag, PUMP2_ON);
}
//Если темп. низа бака больше 85 град.Ц и насос выключен - включаем насос отопления
if (temperature[2]>850 && !(CHECKBIT(flag, PUMP3_ON)) && error_crc[2])
{
PORT_OUTPUT &= ~(1<<PUMP_3);
SETBIT(flag, PUMP3_ON);
}
//Если темп. низа бака меньше 75 град.Ц и насос включен - выключаем насос отопления
if (temperature[2]<=750 && CHECKBIT(flag, PUMP3_ON))
{
PORT_OUTPUT |= (1<<PUMP_3);
CLEARBIT(flag, PUMP3_ON);
}
//Если темп. верха больше 90 град.Ц или какая-либо температура пропала включаем звуковую сигнализацию
if (temperature[3]>900 || !error_crc[0] || !error_crc[1] || !error_crc[2] || !error_crc[3])
{
PORT_OUTPUT &= ~(1<<SIRENA);
SETBIT(flag, SIRENA_ON);
}
//Если темп. верха меньше 80 град.Ц и все температуры в норме - выключаем звуковую сигнализацию
if (temperature[3]<=800 && error_crc[0] && error_crc[1] && error_crc[2] && error_crc[3])
{
PORT_OUTPUT |= (1<<SIRENA);
CLEARBIT(flag, SIRENA_ON);
}
}
}

ARV · Сообщение **ARV** » Ср июн 22, 2016 10:54:11

почему не помогает WDT?

а вот посмотрите, как я вижу ваш код:
1. таймер переполняется каждые 5 мс и сбрасывает WDT
2. WDT настроен на 2,5 секунды
3. спрашивается: если программа "зависла" в главном цикле после разрешения прерываний, сработает ли когда-нибудь WDT?

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

защита от "зависаний" - штука хитрая и слабо поддающаяся формальным рекомендациям... но я бы разбил защиту от зависаний на несколько частей:
1. контроль работы прерываний: в каждом обработчике ставится флаг, видимый из главного цикла, сигнализирующий, что прерывание было
2. контроль работы главного цикла: в главном цикле производится проверка флагов (см. п.1) и, если они установлены за время, когда должны быть установлены, то сбрасывается WDT и сами флаги.

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

иными словами wdt_reset() без какого-то if() - полная бесполезность. сбрасывать WDT следует только если ход работы программы в норме.

предлагаю такой подход: WDT не сбрасывается, если CRC обмена хотя бы с одним термодатчиком не равна 0, если не поступают какие-то входные сигналы, если отдельно взятые участки главного цикла не выполняются определенное количество раз в секунду...

P.S. в некоторых случаях можно рекомендовать и другой способ работы с WDT. настраиваем WDT фьюзами на непрерывную активность, и задаем подходящий интервал его срабатывания. в самой программе НЕ ДЕЛАЕМ главный цикл, а тупо один прогон алгоритма: опросили датчики, выдали сигналы и ушли в сон (например). WDT сработает и запустит очередную итерацию алгоритма. в этом случае в программе вообще не должно быть сброса WDT.

этот подход требует особого обращения с переменными Си, т.к. надо добиться сохранения в них значения с предыдущей итерации алгоритма, а не обнуления после сброса МК, как это обычно делает Си - но это не проблема: все нужные переменные объявляются с атрибутом NOINIT, первоначальная инициализация их осуществляется только после подачи питания (если флаг PORF в MCUСSR установлен после сброса)... и все.

melandr

Дело в том, что я считал, что при зависании МК таймеры тоже перестанут считать. По поводу зависания в основном цикле, если я не делаю цикл, который может стать бесконечным, кроме основного цикла, то зачем мне проверять основной цикл. Поэтому мне нужен сторожевой таймер только от защиты от внешних воздействий. По поводу if() для сброса сторожевого таймера - это мысль, нужно подумать как лучше сделать. То есть контроллер может не выполнять основной цикл, даже если в нем нет условий для зависания программы и в тоже время в прерывании сбрасывать сторожевой таймер? У меня просто основной цикл 12 секунд. Места в тиньке не хватает, чтобы сделать индикацию красивей по флагу.

ARV · Сообщение **ARV** » Ср июн 22, 2016 12:35:23

melandr писал(а):У меня просто основной цикл 12 секунд.

и на здоровье, делайте так:

Код: Выделить всё

while(1){
    // сделали что-то, длящееся 1,5 секунды
    running_is_good = 1; // это флаг-признак нормального выполнения программы, о чем ранее я писал
    // делаем следующую порцию большой длительности, но меньшей периода WDT
    running_is_good = 1;
    ...
    // и так далее, хоть на неделю
}

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

melandr

Да я знаю, что код написан немножко по-колхозному. Но дело в том, что из-за того что 4 датчика на 1-wire и индикация, у меня память тиньки забита на 100%. Потому нет возможности сделать более правильный код. Потом эта отладочная плата будет заменена на другую плату с нормальным контроллером ATmega88/ATmega168. Смотрите какая ситуация сейчас. Трансформаторный блок питания на 12В был заменен на автомобильный аккумулятор. И 80% некорректной работы контроллера прошло. То есть сейчас контроллер вообще не подвисает. У меня выведено в прерывании на светодиод исключающее ИЛИ по счетчику 1 секунда. Так теперь светодиод постоянно моргает каждую секунду. Правда еще есть соединение питания основной платы контроллера и платы реле. планируем поставить для питания платы реле отдельный аккумулятор 6 В или три батарейки 1,5В, для проверки.
ARV, вы не подскажете как схемотехнически организовать сетевое питание для этой платы, чтобы не было помех из сети. Так как на другой плате таймера с таким же блоком питания у меня контроллер подвисал (но в блоке питания был синфазный дроссель и конденсатор). Правда у меня не было гальванической развязки для выходных реле. Вот эта тема
http://radiokot.ru/forum/viewtopic.php?f=2&t=130208

BOB51

Задача собаки или пробуждение МК в режиме останова (сонный останов) или сброс в случае неконтролируемого останова в произвольной точке программы (частный случай - останов главного тактового генератора). Контроль питания ведут системы BOD и POR.
Питание нужно подавать в соответствии с потребляемой мощностью (учитывая реакцию на импульсный отбор при подключении катушек реле).
Ну и так далее...

melandr

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

BOB51

Матчасть учить надо!

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

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

Иначе будет как у мага-недоучки:
"сделать хотел Грозу, а получил КоЗу (розовую КоЗу в желтую полосу)"

КРАМ

melandr писал(а):Просто почему-то когда программа переставала выполняться из-за сетевых помех, собака не сбрасывала контроллер, почему не знаю.

Программа не может "перестать выполняться". Контроллер не имеет режима HALT иначе чем в режиме глубокого сна.
Программа может пойти по несанкционированному пути. Но выполняться она при этом не перестает.
ЗЫ. Опубликовали бы Вы свою схему и внешний вид печатной платы устройства.

ARV · Сообщение **ARV** » Чт июн 23, 2016 08:02:05

КРАМ писал(а):Программа не может "перестать выполняться"

чисто теоретически - может, например, из-за остановки тактового генератора, или попадания микропрограммного автомата в непредусмотренное состояние... но вероятность такого события, конечно, очень мала, и так же маловероятно, что оно произойдет без фатального повреждения МК (например, "пробивание" кристалла космической частицей с высокой энергией)