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

[orionSSV]

Доброго времени суток господа. Ни когда до сих пор не пользовался форумом в качестве решения своего конкретного вопроса. Но форумы этого портала весьма эффективны! Итак...
Суть задачи такая : с нескольких удалённых объектов снимаются их состояния. Всего состояний 4 (в аналоговом виде), после декодирования они в 3-х битном состоянии подаются в входы скажем PORTA.0, PORTA.1 и PORTA.2. Их значения (на выходе декодера) 0х0, 0х1, 0х2, 0х3 (ну или 0b000, 0b001, 0b011, 0b111). Опрос объектов (всего 6 штук) производится последовательно. Реализовано на 6 реле которые коммутируют объекты по очереди к одному декодирующему блоку. Управляются реле PORTB (через соответствующие развязки), на выходах которого поочерёдно появляется "1" с нулевого по 6 бит порта (в цикле итерация которого инициируется прерыванием от таймера Т1). Проблема следующая: ни как не могу сделать так чтобы в процессе опроса программа запоминала состояния объектов, чтобы в последствии скажем вывести на индикаторы. Работаю в Proteus, программа пишется в CodeVisionAVR. Камень Atmega 8515. При необходимости с радостью предоставлю файлы этого устройства для критики.
С уважением и надеждой, я))

[ut1wpr]

Проблема следующая: ни как не могу сделать так чтобы в процессе опроса программа запоминала состояния объектов, чтобы в последствии скажем вывести на индикаторы.

Считывание значения объекта с порта в переменную с именем этого объекта уже есть память состояния. Вопрос, на какую глубину во времени вам нужно сохранять эти данные. Обычно в таких случаях организуют стек (массив) в памяти. Глубина стека определяется исходя из ваших требований (вы их не оглашали, увы.). Подобные устройства носят названия логгеры или регистраторы. Исходя из требований их часто реализуют на SD/MMC картах или других типах долговременной памяти. Повторяю, исходя из условий. Которых мы не знаем.

[EagleB3]

Проблема следующая: ни как не могу сделать так чтобы в процессе опроса программа запоминала состояния объектов, чтобы в последствии скажем вывести на индикаторы

В целом присоединяюсь к предыдущему посту, но немножко конкретизирую вопросы. Идти надо от конца к началу.
Обычно конечная цель все же анализ данных от датчиков. Поэтому вопросы, которые Вы заранее четко должны решить для себя

g) Кто, как, чем и где будет анализировать данные.
f) Перед этим - какая-то предварительная обработка данных.
e) Перед этим - передача данных (например в компьютер...). Может быть не надо вообще.
d) Перед этим - в каком виде и сколько времени хранить данные до передачи (обработки). Энергонезависимость. Каков общий объем данных. Как и когда удалять ненужные данные.
c) Перед этим - как помещать данные в хранилище.
b) Перед этим - как и в каком виде получать данные.
a) Какие вообще требуются индикаторы (этапы "b".."g" и эксплуатация прибора).

Вы пока справились с этапом "b", и просите совета по этапу "c".
Нельзя что-то предметно советовать по этапу "c", если не известны требования к этапу "d".

Вот как-то так...

они в 3-х битном состоянии подаются в входы скажем PORTA.0, PORTA.1 и PORTA.2. Их значения (на выходе декодера) 0х0, 0х1, 0х2, 0х3 (ну или 0b000, 0b001, 0b011, 0b111).

4 состояния описываются 2-мя битами (0b00, 0b01, 0b10, 0b11).
А 0b111 = 0x07

В 3 бита Вы можете затолкать 8 состояний, т.е., при желании, добавить к нынешним 4-м состояниям еще 4 служебных (например, "обрыв", "короткое", "не ответил" и т.п.).

[ut1wpr]

В целом присоединяюсь к предыдущему посту, но немножко конкретизирую вопросы. Идти надо от конца к началу.
Обычно конечная цель все же анализ данных от датчиков. Поэтому вопросы, которые Вы заранее четко должны решить для себя

g) Кто, как, чем и где будет анализировать данные.
f) Перед этим - какая-то предварительная обработка данных.
e) Перед этим - передача данных (например в компьютер...). Может быть не надо вообще.
d) Перед этим - в каком виде и сколько времени хранить данные до передачи (обработки). Энергонезависимость. Каков общий объем данных. Как и когда удалять ненужные данные.
c) Перед этим - как помещать данные в хранилище.
b) Перед этим - как и в каком виде получать данные.
a) Какие вообще требуются индикаторы (этапы "b".."g" и эксплуатация прибора).

Вы пока справились с этапом "b", и просите совета по этапу "c".
Нельзя что-то предметно советовать по этапу "c", если не известны требования к этапу "d".

Вот как-то так...



4 состояния описываются 2-мя битами (0b00, 0b01, 0b10, 0b11).
А 0b111 = 0x07

В 3 бита Вы можете затолкать 8 состояний, т.е., при желании, добавить к нынешним 4-м состояниям еще 4 служебных (например, "обрыв", "короткое", "не ответил" и т.п.).

Господи, да зачем вам это?! Вы собрались за коллегу его работу выполнить? Вопрос как изначально стоял?

[orionSSV]

Отлично. мгновенная реакция на тему. Огромное спасибо всем!
Как метко подметил уважаемый EagleB3, состояния действительно отображают именно "обрыв", "короткое", "тревога" и "охрана". Все эти состояния передаются с объектов по 2-х проводному соединению и характеризуются изменением сопротивлений, и как следствие падением напряжения на этом объекте. У меня хватило ума реализовать дешифратор на 3 компараторах, выходы которых и есть: обрыв - 0b000, охрана - 0b001, тревога - 0b011, короткое - 0b111. По поводу глубины времени. Уважаемый ut1wpr, хранить состояния достаточно до нового опроса всех реле. А вот тревожные состояния нужно хранить до сброса, при этом новые состояния уже не учитываются (я знаю как это реализовать). индикация примерно следующая : обрыв -красный , охрана - зелёный, тревога - мигающий красный, короткое - перемигивание зелёным\красным (как реализовать знаю). Не получается сделать именно фиксирование состояний в какой нибудь массив buf[6] или переменным sensor1,sensor2...

[orionSSV]

g) Кто, как, чем и где будет анализировать данные.
f) Перед этим - какая-то предварительная обработка данных.
e) Перед этим - передача данных (например в компьютер...). Может быть не надо вообще.
d) Перед этим - в каком виде и сколько времени хранить данные до передачи (обработки). Энергонезависимость. Каков общий объем данных. Как и когда удалять ненужные данные.
c) Перед этим - как помещать данные в хранилище.
b) Перед этим - как и в каком виде получать данные.
a) Какие вообще требуются индикаторы (этапы "b".."g" и эксплуатация прибора).

g) Анализ данных . Кто - первая ступень АЦП, реализованный на компараторах, вторая - входы МК на которые идет результат АЦП. КАК - чтение входов МК на которые идет результат АЦП и выполнение определённых действий.
f) Только АЦП- преобразование в понятный для МК вид информации (АЦП не контроллера)
e) Передача только с объекта контроля (сторожевой датчик) по двухпроводной линии. Сигнал аналоговый.
d) Состояние "охрана" только на период опроса, все остальные до сброса и без обновления состояний(заморозить).
c) Интересный вопрос. Это как раз часть моей проблемы. Можно в созданный буфер, можно глобальными переменными... м?
b) Видимо это ответ на пункт e)
a) индикаторы - двух цветовые (красный\зелёный) светодиоды + звуковое оповещение.

[Godzilla82]

Посоветовал бы использовать другой камень. Например ATmega16. У неё встроенный 8-канальный АЦП. Не придётся ничего коммутировать, да ещё такими устройствами, как реле. 8 ног - 8 независимых входов.

Программа по таймеру (например, с интервалом 1 сек) опрашивает состояние 6 объектов и запоминает их в памяти.

После опроса данные анализируются. И если возникло какое-то важное событие - то устанавливается флаг этого события.

Камушек по RS-232 связывается главным компьютером. Запущенная на ПК программа с интервалом (допустим, 2 сек) опрашивает МК.

МК ей передаёт как текущие состояния объектов, так и флаги.

По определённой команде флаги могут сброситься (ложная тревога).

Можно сделать так, что МК сам с интервалом 1 минуту передаёт состояние объектов. А если случилось событие - передаёт состояние немедленно.

Если программе на ПК за 2 минуты (ну примерно это всё) не пришло данных от МК, то это также аварийная ситуация.

Данные желательно зашифровать.

например:

 
interrupt [TIM0_COMP] void timer0_comp_isr(void)
{
scan = 0;
}

interrupt [TIM1_COMPA] void timer1_compa_isr(void)
{
send = 0;
}

unsigned char GetState(unsigned char channel)
{
unsigned int a;
a = GetADC(channel);
switch(a)
  {
  case 0 .. 400: 
  return STATE_1;
  break;
            
  case 401 .. 600:
  return STATE_2;
  break;

  case 601 .. 800:
  return STATE_3;
  break;

  default
  return STATE_4;
  }
}

int main(void)
{
unsigned char i,j;
begin:
if(scan == 0) {
              for(i=0; i‹6; i++) {
                                 states[i] = GetState(i);
                                 j = states[i] & MASK_ERROR;
                                 if(j == 0) continue;
                                 if(j & errors[i] == 0) {
                                                        errors[i] |= j;
                                                        send = 0;
                                                        }
                                 }
              scan = 1;
              }

if(send == 0) {
              for(i=0; i‹6; i++) {
                                 SendUART(states[i]);
                                 SendUART(errors[i]);
                                 }
              send = 1;
              }
goto begin;
} 

[orionSSV]

Посоветовал бы использовать другой камень. Например ATmega16. У неё встроенный 8-канальный АЦП. Не придётся ничего коммутировать, да ещё такими устройствами, как реле. 8 ног - 8 независимых входов.

Желательно конечно использовать уже имеющийся камень...Хотя Atmega тоже не проблема. Хм... Может даже в этом есть определённый смысл. И кстати необходима развязка тогда, цеплять шлейфы блиною до 20м к ноге МК весьма сомнительное занятие)).
Зато к компу подключать нет нужды. Это просто охранное устройство к тщательным контролем состояния шлейфов.
сейчас ознакомился с ДШ камня. Конечно на порядок выше 8515...

[Godzilla82]

И кстати необходима развязка тогда, цеплять шлейфы блиною до 20м к ноге МК весьма сомнительное занятие)).
Зато к компу подключать нет нужды. Это просто охранное устройство к тщательным контролем состояния шлейфов.

Ну куда его подключать - решать вам. Это для примера.

Ну и входная цепь:

[avric]

Правильно ли я понял, что у вас просто не считываются состояния портов?
Если да, то просто надо читать не PORTA, а PINA (см. раздел о GPIO в даташите).
states[i] = PINA & 0x07; // оставляем нужные 3 бита

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

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