Важный кусок программы для ATmega

[BolshoyK]

Еще намек. В байте 8 бит.
в нем можно хранить 4 сохраненных ранее состояния объекта, если использовать по 2 бита на 1 замер (2 бита - 4 состояния объекта, как уже сказали ранее).
a - байт с данными.
a1 = a & 0x03;
a2 = (a ›› 2) & 0x03;
a3 = (a ›› 4) & 0x03;
a4 = (a ›› 6) & 0x03;
Так можно прочитать все 4 запомненных состояния для анализа.

[EagleB3]

g) Анализ данных . Кто - первая ступень АЦП, реализованный на компараторах, вторая - входы МК на которые идет результат АЦП. КАК - чтение входов МК на которые идет результат АЦП и выполнение определённых действий.

Нет, не это. Конечный анализ выполняет человек. Под него строится интерфейс, а под интерфейс - хранение и обработка данных.
a) Либо человек сидит рядом дивайсом, и, услышав пищалку, смотрит на дивайс, видит красный светодиод, как-то реагирует (включает сирену, звонит начальнику, стреляет в воздух - нужное подчеркнуть ) и жмет на дивайсе кнопку "Сброс".
b) Либо человек раз в сутки (или с нужной периодичностью) просматривает журнал системы и очищает его после просмотра.
c) = a + b.

Для варианта "b" нужно (можно...) хранить историю событий. Событие = смена состояния канала. То есть в каком-то массиве хранить номер канала + состояние канала + время перехода в это состояние. Так определится количество памяти, потребное для фиксации одного события. Дальше прикидываем количество событий, которое может потребоваться зафиксировать (теоретический верхний предел - полное количество опросов за период между чтениями истории + некий процент в запас на пересменку и опоздания).
Ну хорошо, история событий не нужна. В эту тему не углубляемся.

Для варианта "a" Вам достаточно просто "защелкнуть" на индикаторах состояние, отличное от "Охрана". Снимаете защелку кнопкой "Сброс". Общей или индивидуальной по каждому каналу охраны. Примерный сценарий:
Опрос - обнаружена "тревога" по каналу 5 - загорелся красный диод канала 5. Очередной опрос - в канале 5 "Охрана", но красный светодиод не гаснет. Очередной опрос - обнаружена "закоротка" по каналу 6 - загорелось перемигивание на канале 6. И так они и горят ("тревога" на канале 5 и "закоротка" на канале 6), пока кнопку "Сброс не нажмут. Если, конечно, еще в каком-то канале что-то не стряслось.
Оборвалось-восстановилось питание - индикация пришла в то же состояние ("тревога" на канале 5 и "закоротка" на канале 6).
Нажали кнопку "Сброс" - всем каналом сохранено состояние "Охрана", индикация по всем каналам = "Охрана" (или вообще полностью погасить. Включить по результатам первого опроса).

Я правильно понял идею?

Если да, то развиваю:
1) Время поступления сигнала по каждому каналу не фиксируется (иначе придется еще и часы/календарь в систему добавлять).
2) Для индикации по описанному мной принципу не нужно организовывать никаких массивов данных. Да и возня с битовыми масками теряет смысл - плотная упаковка данных не нужна. Достаточно хранить 6 глобальных переменных (по одной на каждый канал).
3) У состояний должен быть приоритет. При смене состояния "защелкивается" (и индицируется) состояние с более высоким приоритетом, а смена на состояние с низшим приоритетом игнорируется. У состояния "Охрана" - приоритет низший, у состояния "Тревога" - наивысший. То есть, если линия в состоянии "Тревога", а в очередном опросе этой же линии пришла "Закоротка", должна остаться индикация "Тревога". Если линия в состоянии "Закоротка", а в очередном опросе этой же линии пришла "Тревога", индикация должна смениться на "Тревога". Состояния "Закоротка" и "Обрыв" - идеологически равны, но кого-то придется сделать условно приоритетнее за-ради упрощения алгоритма.
Либо заведите по два диода на канал. Один - под "Охрана-Тревога", другой - под технологические "КЗ-Обрыв". И тогда по две переменных состояния на каждый канал.
4) Хорошо бы понять с какой частотой Вы будете делать опрос, и с какой - "освежать" индикацию. Ячейка, отведенная под хранение состояния в EEPROM Atmel выдержит ок.100000 перезаписей. Потом умрет. Итого, 100000 циклов опроса. Можно подумать о внешней EEPROM с большим числом перезаписей или выделять ячейку "по-хитрому".
5) Не надо заниматься ничем существенным внутри прерывания. Внутри прерывания просто взводите флаг "опрос" (глобальная переменная volatile), если он сброшен.
А вот в основном цикле программы, если не установлен флаг "опрос", ничего не делайте (но не забудьте о кнопках!!!). Если установлен флаг "опрос" - опрашивайте датчики, меняйте переменные состояния, меняйте индикацию и сбрасывайте флаг "опрос".
6) Насчет помнить о кнопках: их надо будет опрашивать. Либо в основном цикле вместо "ничего не делайте", либо по отдельному прерыванию либо... Вариантов много. Но чтобы вышло дельно - надо учитывать частоту опроса, длительность цикла опроса-индикации и т.п.

7) Насчет датчиков и линий связи...
Сама идея передачи аналогового сигнала на 20 метров не очень нравится.
Если там будут какие-то реле - я надеюсь, не механические? Зачем вообще реле? Вы собирались коммутировать 6 датчиков на один сигнальный провод? Если у Вас топология "шина" - то может быть, может быть. Если топология "звезда" - коммутация только вредит, КМК.
Но даже если у вас "шина", то я бы все же поискал какие-нибудь дешевые АЦП с человеческим интерфейсом (I2C или SPI) и поставил бы их в датчиках (выйдет не намного дороже возни с реле, но опрашивать - сплошное удовольствие).

[orionSSV]

Огромное спасибо всем откликнувшимся!!! Каждый пост так или иначе мне помог.
Отдельно EagleB3! 100%-ый охват проблемы. Отвечу так же объемно.
Идея с защёлкиванием состояний понята вами правильно. Именно так и планируется реализовать. Сброс для всех один. Хранение не требуется, предполагается привлечение внимания вплоть до реакции со стороны человека и/или (это опционально) дозвон по некоторому номеру сотового телефона.
1) верно.
2) Глобальные переменные или массив.
3) +1вам за идею! О приоритете состояний я не думал, их у меня было два "Охрана" и все остальное))
4) здесь нужны некоторые уточнения ибо это как раз область моих затруднений...
По условию оконечным устройством может быть что угодно, результатом срабатывания которого было бы замыкание контактов,а так же необходимость передать не только факт замыкания контактов, но и события "КЗ" и "обрыв". Я решил сделать это на основе симметричного делителя напряжения, у которого если одно плечо станет асимметрично, то напряжение изменяется довольно сильно и предсказуемо)). Таким образом я додумался до этого: Из-за отсутствия АЦП у МК, мне пришлось делать его на компараторах. С целью избежать необходимости вешания компаратора на каждый канал (это было бы крайне затруднительно, т.к. или 3 выхода у каждого компаратора * 6=24бита портов из 35 возможных, были бы заняты только под каналы или сводить 4 состояния на 3 выходах в 2 бита напаиванием логики... ), я решил осуществлять поочерёдную коммутацию каналов к одному АЦП, с цифровыми ключами умеющими передавать аналоговый сигал я дел не имел, поэтому выбрал меленькие твердотельные реле. Поэтому время опроса у меня 0.4 сек на одно реле то есть время опроса всех реле =2,4 сек. И кстати о конечности числа записи в EEPROM я не задумывался... Хотя те же переменные о состоянии вроде как должны храниться в SRAM...
5)Хм... О подобном упоминал и уважаемый avric.

Далее, о запоминании состояния в прерывании. Если вы так и делаете, то переменные, в которые вы сохраняете состояния, следует объявлять с атрибутом volatile, например:
char volatile states[CHANNEL_COUNT];

Нужно будет ознакомится поподробнее.

Внутри прерывания просто взводите флаг "опрос" (глобальная переменная volatile), если он сброшен.

Т.е. Выполнять какие -либо действия в теле основного цикла, при условии что тот или иной флаг сброшен и устанавливать по окончанию этих действий... я верно понял?
6) кнопок будет не более трёх. Я реализовал их опрос в главном цикле.
цикл опрос-индикация: я предполагал, что цикл индикации будет постоянным, но с результатом зависящим от результата цикла опроса. И ВОТ ЭТО ИМЕННО ТО МЕСТО ГДЕ Я ВСТАЛ В ТУПИК. Возможна сама идея нерациональна, я не исключаю и этого))
7)

Сама идея передачи аналогового сигнала на 20 метров не очень нравится.
Если там будут какие-то реле - я надеюсь, не механические? Зачем вообще реле? Вы собирались коммутировать 6 датчиков на один сигнальный провод? Если у Вас топология "шина" - то может быть, может быть. Если топология "звезда" - коммутация только вредит, КМК.
Но даже если у вас "шина", то я бы все же поискал какие-нибудь дешевые АЦП с человеческим интерфейсом (I2C или SPI) и поставил бы их в датчиках (выйдет не намного дороже возни с реле, но опрашивать - сплошное удовольствие).

Частично я уже ответил, это где номер 4)). Видите ли существует ограничение в в том, что устройство датчика нам неизвестно и может быть любым, вплоть до геркона или чего-то подобного... Нам дается только сухой нормально разомкнутый контакт. Контакт и шлейф, длиною до 20м. По поводу коммутации. Это не принципиально - это вынужденная мера,избежание которой - только плюс.

[ivanbalandin]

Года два назад разрабатывал подобную систему.
Основа центрального блока ATMEGA32.
Все события в системе фиксировались по времени - была введена ИС часов реального времени, со встроенным ОЗУ и независимым питанием.
Для снятия ограничения по количеству записей в ячейки EEPROM использовалась внешняя ИС с I2C. Запись в ячейки производилась по кругу, при заполнении запись начиналясь с начальной ячейки. Номер текущей свободной ячейки сохранялся в ОЗУ часов.
Информация выводилась в текстовом виде на графический индикатор, в качестве которых использовались газоразрядные индикаторы. При тестировании использовался и ЖК индикатор.
Т.К. охраняемая территория и число объектов было значительным, для уменьшения числа соединительных линий использовались внешние блоки датчиков. Каждый блок опрашивал до 8 датчиков, основа - ATTINY24 или ATTINY13 (с внешним мультиплексором) со встроенным АЦП. Каждый блок датчиков соединялся с центральным блоком по отдельной двухпроводной линии, опрашиваемый блок выбирался мультиплексором, использовалась гальваническая развязка на оптронах. Передача осуществлялась с помощью токовой петли, и USART, скорость 1200, в ATMEGA32-аппаратный ATTINY-програмный. Питание блоков датчиков осуществлялось по этим же линиям, всего предполагалось использовать 16 блоков датчиков. Проверка показала устойчивую работу со встроенным RC генератором в ATTINY в диапазоне температур -30...+30С и длиной соединительных линий до 1800. Изменения состояния соединительных линий, параметров устройства (наличие резервного питания и сети) также записывалось в EEPROM.
К сожалению проект не был внедрен, в организации прошли структурные изменения и была внедрена система С-2000.

[Faworit]

Добрый день. Вроде подобной задачи, было решено на тиньке 26-й, 10 аналоговых входа, выход на линейку светиков + несколько кнопок управления и коммутирующий выход. Так вот аналоговые входа работали через оптопары. Дальность до датчиков, от 5м до 150 метров и все работало в условиях цеха.

[EagleB3]

Из-за отсутствия АЦП у МК, мне пришлось делать его на компараторах.

Ну, это не проблема. Есть дешевые АВР-ы с 8-ю и даже с 10-ю ADC на борту. Но я бы все же присмотрелся бы к, скажем, внешним ADC H28. За 150 рублей - интерфейс I2C с микропотреблением. Но, как говорится, "хозяин-барин". Хотите с переключением - делайте с переключением.

Выполнять какие-либо действия в теле основного цикла, при условии что тот или иной флаг сброшен и устанавливать по окончанию этих действий... я верно понял?

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

Допустим, Вам надо делать опрос датчиков 20 раз в секунду; настраиваете прерывание по таймеру с этой частотой.
Опрашивать кнопку (антидребезг) можно, скажем, с частотой 10 Гц; если три раза будет зафиксировано одно и тоже состояние кнопки, значит, кнопка нажата (или отпущена).

В прерывании проверяете и, если сброшен, устанавливаете флаг "F1".
В основном цикле, если установлен флаг F1,
1) Опрашиваете датчики;
2) Инкрементируете счетчик "Цикл кнопки". Проверяете - если он больше 1 (т.е. каждый второй цикл) счетчик "Цикл кнопки" обнуляете и выполняете опрос состояния кнопок (и там же разбираетесь с дребезгом).
3) Сбрасываете F1.

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

Решение от ivanbalandin, с внешним ОЗУ в часах (со своей бекапной батарейкой!) и внешним EEPROM, КМК, очень правильное.

[Godzilla82]

Идея с защёлкиванием состояний понята вами правильно. Именно так и планируется реализовать.

Я приводил участок кода. Там реализован именно этот принцип.

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

Как только возникнет ещё одно подобное событие, которого не было раньше, также будет установлен флаг немедленного сообщения и оно добавится к "списку происшествий".

Из-за отсутствия АЦП у МК...

Купите вы нормальный камень и сразу станет намного проще, легче, быстрее и надёжнее. Всего за какие-то 100-200 руб.

Нужно будет ознакомится поподробнее.

Квалификатор volatile актуален для WinAVR. В CodeVision не стоит заморачиваться.

Т.е. Выполнять какие -либо действия в теле основного цикла, при условии что тот или иной флаг сброшен и устанавливать по окончанию этих действий... я верно понял?

Да. Для более лёгкого понимания надо говорить "если флаг установлен". Но вы, наверное, увидели у меня 0 и подумали, что флаг сброшен.

Это сделано в целях увеличения быстродействия. На обнуление переменной уходит меньше тактов. Хотя, может я и ошибаюсь.

кнопок будет не более трёх.

 
      if (!PINA.1) {
                   if ( (cnt1==0) || (cnt1==20) ) Press_1();
                   if (cnt1‹20) cnt1++;
                   }
      else cnt1=0;
      if (!PINA.2) {
                   if ( (cnt2==0) || (cnt2==20) ) Press_2();
                   if (cnt2‹20) cnt2++;
                   }
      else cnt2=0:
      if (!PINA.3) {
                   if ( (cnt3==0) || (cnt3==20) ) Press_3();
                   if (cnt3‹20) cnt3++;
                   }
      else cnt3=0; 

Этот код при нажатии на кнопку вызывает соответствующую функцию. Если кнопка нажата более двух секунд - ускоренный вызов функций.

Для правильного функционирования время между опросами должно быть примерно 100 мс.

Этот код можно повесить и на прерывание таймера с интервалом 100 мс. Тогда более логично было бы не вызывать функции, а устанавливать флаги нажатой кнопки. А в основной программе уже делать всё, что надо.

[avric]

Квалификатор volatile актуален для WinAVR. В CodeVision не стоит заморачиваться.

volatile актуален для языка Си. Если в codevision он пока не играет никакой роли, то это вероятно лишь потому, что ещё нет соответствующей оптимизации. Когда-нибудь обновите свой любимый компилятор и обнаружите, что вновь скомпиленные старые проги не работают. Вот так и появляются чудаки, уверенные в том, что "последняя версия ‹моей_любимой_программы› - полный отстой"!

Какие-то оптимизации, взвод флагов - и всё это вместо банального запихивания значения в переменную. Да ещё и в прерывании, на обработку которого уйдёт от силы 100-150 тактов (это в случае, если на него повесить всё - чтение, обработку - сравнение с предыдущим состоянием, индикацию со всем горениями-морганиями-морзянкой), а вызывается оно, десяток-другой раз в секунду. Что вы боитесь пропустить за эту сотню тактов?

[orionSSV]

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

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

Но при этом (когда работает функция "немедленного сообщения") опрос объектов производится так? Ведь прерывание же...

[Godzilla82]

volatile актуален для языка Си. Если в codevision он пока не играет никакой роли, то это вероятно лишь потому, что ещё нет соответствующей оптимизации.

Ну зачем же так... Он и в CV работает. При volatile переменная размещается в памяти. И заметно уменьшение быстродействия.

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

Но при этом (когда работает функция "немедленного сообщения") опрос объектов производится так? Ведь прерывание же...

Всё выполнятеся по-очереди. Сначала опрос объектов. Затем анализ результатов. Если авария - возводится флаг. Затем доходит очередь до блока индикации. Это может быть как зажжёный светодиод, так и включение пищалки.

Зажгли светодиод - и снова опрашиваем состояние объектов.

Ну забыл ещё где-то идёт опрос флагов нажатых кнопок. Если нажимали - соответствующая реакция. Тоже быстрая. Сбросили события, потушили светодиод - и снова опрашиваем состояния.