Сохранение важных переменных в EEPROM при потере питяния Опции

[ATMExpert]

Бодрого дня всем форумчанам. В моем проекте (на Mega640) требуется в момент пропадания общего питания сохранять 5-6 байт оперативной информации в еепром, дабы иметь возможность при подаче питания благополучно их считывать. Аппаратно для этих целей использую встроенный компаратор с внешней опорой (REF192) и делитель по питанию. В программе ставлю прерывание на компаратор, ну и пишу в еепром. Схема питания такая: +24-->+12-->diode-->condencator 2200 uF-->+5. При пропадании +24 схема детектирует просадку, вызывается прирывание. Конденсатор 2200 мкФ думаю достаточен, чтобы успеть записать в память до снижения питания ниже критического уровня. В железе показывает достаточно устойчивую работу (в лаб. условиях). Хочется услышать мнения по такой реализации, а также может нужно еще что-то в код добавлять если после успешной записи остается время (может нужно ожидать с ноги выхода компаратора смену уровня, если это была кратковременная просадка питания).

[aaarrr]

Конденсатор 2200 мкФ думаю достаточен

Это лучше подсчитать, чтобы иметь уверенность. Возможно, лучше будет перенести конденсатор на +24 или +12, если там нет мощных потребителей, ибо U^2.

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

Можно, только с длительным debouncing'ом от греха.

[V_G]

Я в xmegy успеваю сохранить страницу (32 байта) при конденсаторе на питании по 3,3 В 100 мкФ.
Проверял так: после аварийной записи EEPROM анализировал соотв. флаг готовности и после его выставления в ком-порт в цикле начинал сыпать байты. Сколько байт придет в компьютер, примерно такой запас (в попугаях) по времени имеется до критического понижения питания

[zombi]

... если после успешной записи остается время ...

Я бы ждал время за которое кондёр по питанию должен точно разрядиться.
Если этого не происходит, значит "фигня" с питанием, и в этом случае вижу 3 варианта дальнейших действий:

1. ничё не делаем и работаем дальше.
2. уходим на програмный сброс.
3. "радостно" сообщаем о плохом питании с дальнейшим п1 или п2.

Ну и BOD мк обязательно должен быть включён.

[ATMExpert]

Кондер стоит по 12 вольтам. от этой же напруги питается dc-dc на 5 вольт(Мега и логика). А диод после +12 стоит, он и отсекает всю нагрузку по этой линии питания. BOD стоит внешний вместе с WDT. Я мог проверить факт попадания в процедуру прерывания тупо уменьшая входное питание от БП. Делитель расчитал вроде верно с достаточным запасом. При 19 вольтах появляется сработка. Вот п/п от компаратора:

Код

__interrupt void MainPowerFail(void)
{
  asm("cli");
  if ((!drv_pan.drv_on)&&(!drv_tilt.drv_on))   // если тока приводы не включены - значит можно сохранить, а иначе нет смысла
    {Wr_Ee_Int((int)&PanFailPos, drv_pan.pos_pan); //сохраняем данные
     Wr_Ee_Int((int)&TiltFailPos,drv_tilt.pos_tilt);
     Wr_Eeprom((int)&ErrorFlag, (SYSTEM_STATUS|POS_SAVED));
     while (bit_is_set(ACSR, ACO)){}  //ждемс пока питание не восстановится
    }
}

Так можно решить задачу ожидания восстановления питания?

[aaarrr]

Так можно решить задачу ожидания восстановления питания?

Так не стоит: нужно дождаться стабильного восстановления питания, а не вылетать по любому шороху от компаратора.

[ATMExpert]

Дык вот этой строчкой и жду вроде как:

while (bit_is_set(ACSR, ACO)){} //ждемс пока питание не восстановится
Ну а если не восстановится...на сем и заканчиватся работа...

Жаль я прознал о Ramtron'e недавно. Интерфейсы в трех вариациях имеются: parall, spi i2c. По моему - наиболее идеальное решение, не считаете так?

[aaarrr]

Дык вот этой строчкой и жду вроде как:

В том-то и дело, что не ждете: ждать нужно не единичного события на выходе компаратора, а нормального уровня в течение достаточно длительного времени.
Иначе есть шанс вылететь совсем не вовремя.

[ATMExpert]

В том-то и дело, что не ждете: ждать нужно не единичного события на выходе компаратора, а нормального уровня в течение достаточно длительного времени.
Иначе есть шанс вылететь совсем не вовремя.

Т.е. дебоунс однозначно? Тогда в этот цикл ожидания задержку милисек так на 100 и повторно зырить состояние ноги?

[aaarrr]

Т.е. дебоунс однозначно?

Без него получится потенциальный источник проблем: если компаратор начнет болтаться (а кто его знает, как себя может повести питание при аварии?), то можно легко испортить запись в EEPROM.

Тогда в этот цикл ожидания задержку милисек так на 100 и повторно зырить состояние ноги?

Не задержку, а постоянно на протяжении 100 миллисекунд смотреть линию. Процессору все равно в это время больше нечем заняться.

[ILYAUL]

1. Что мешает сразу сохранять данные в EEPROM?
2. Будут ли актуальны эти данные после , например , часа простоя системы?
3. После диода стоит стабилизатор на 5 В?

[zombi]

При 19 вольтах появляется сработка.

Т.е. при повышении питания происходит ложная сработка?

[ATMExpert]

1. Что мешает сразу сохранять данные в EEPROM?
2. Будут ли актуальны эти данные после , например , часа простоя системы?
3. После диода стоит стабилизатор на 5 В?

1. Данные - это по сути текущие координаты привода (вертикаль и горизонт). Их имеет смысл сохранять только когда привод стоит на месте, иначе если во время движения привода пропадет питание, актуальность их в еепроме никакая, т.к. любой привод имеет некую инертность и не сразу остановится. Мы используем шаговые движки без обратной связи (без энкодеров).
2. Само собой данные будут актуальны через любое кол-во времени.
3. Да, после диода стоит стаб. 5 вольтоф

Т.е. при повышении питания происходит ложная сработка?

Нет, сработка происходит при понижении питания, и как уже отмечалось, в п/п прерывания от компаратора сидим и ждем пока либо питание не восстановится, либо ждем конца света)))

aaarrr, твои подсказки по ожиданию выхода(невыхода) из обработки прерывания применю обязательно, спасибо!


А никто и не сказал кстати, применяли ли в проектах ферроэлектрик энергонезвисимую мемори от Рамтрона?

[ILYAUL]

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

Вы не находите в своих словах не стыковку. Вы не знаете точно , что произошло после последних сохранённых данных.Т.е. после вкл. питания и до его внезапного отключения произошли события изменившие настройку приводов или они находились в движении в этот момент. Но у Вас в EEPROM остались старые данные. По существу Вы не знаете в каком положении находится привод. Не проще сделать -запись EEPROM затем делать шаг двигателя , запись - шаг. Так у Вас всегда есть координаты привода +/- шаг
3.

Да, после диода стоит стаб. 5 вольтоф

Лучше до диода

[ATMExpert]

Вы не находите в своих словах не стыковку. Вы не знаете точно , что произошло после последних сохранённых данных.Т.е. после вкл. питания и до его внезапного отключения произошли события изменившие настройку приводов или они находились в движении в этот момент. Но у Вас в EEPROM остались старые данные. По существу Вы не знаете в каком положении находится привод. Не проще сделать -запись EEPROM затем делать шаг двигателя , запись - шаг. Так у Вас всегда есть координаты привода +/- шаг

Представляете на сколько хватит еепром если в нее писать после каждого шага? До внезапного отключения питания может происходить что угодно. При норм. питании текущие координаты лежат в ОЗУ, верно? Верно. Факт пропадания питания фиксируется? Еще как! Так вот если привод в этот момент вращался, то нет нужды сохранять эти координаты. После такого режима проводится рекалибровка привода по крайним положениям однозначно. А вот если привод стоял в это время, мы и запишем то, где он остался стоять. Ну а после подачи питания нагло прочтем сохраненное, и мы в корректных координатах. В след. версии поставлю FM25xx или FM24xx. В нее хоть можно смело писать каждый раз после команды стоп.

[zombi]

В след. версии поставлю FM25xx или FM24xx. В нее хоть можно смело писать каждый раз после команды стоп.

Как часто поступает команда стоп?

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

Как Вы определяете что движение закончено?

[ATMExpert]

Как часто поступает команда стоп?

Как Вы определяете что движение закончено?

Это протокол обмена Pelco-D. Команда стоп подается от хоста. Не чаще думаю, чем 1 раз в сек. Это если ручное управление (или джойстик). А если подаются команды типа переместиться на столько-то шагов в таком-то направлении, то девайс есесно сам останавливает себя. А определять, когда движение закончено помогают концевые оптодатчики. При начальной инициализации привод перемещается от крайней до крайней позиции, передает максимальные координаты хосту (по запросу). Если движение происходит без пропуска шагов, то энкодеры можно и не ставить. А если уж пропуск случится, то повторная калибровка в помощь.

[zombi]

А если подаются команды типа переместиться на столько-то шагов в таком-то направлении, то девайс есесно сам останавливает себя.

Вот я и спрашиваю : как Вы определяете что девайс закончил выполнение последней команды и можно посылать новую?

[demaven]

в одной из работ потребовалось сохранять небыстро меняющуюся информацию при пропадании питания. для достоверности сохранять пришлось в ЧЕТЫРЕХ ячейках и при считывании проверять по мажоритару. пропадание питания может происходить при записи в любую ячейку, может быть - порченая три старые; новая три старые; новая, порченая две старые; две новые две старые; две новые, порченая, одна старая; три новые старая; три новые порченая. каждая ячейка включала в себя црц, чтобы определить подлинность. видно, что только в одном случае нельзя восстановить новую информацию, но сохраняется старая. от заказчика претензий ни разу не поступало уже несколько лет, хотя питание довольно часто выключается внешними воздействиями

[ATMExpert]

в одной из работ потребовалось сохранять небыстро меняющуюся информацию при пропадании питания....

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

как Вы определяете что девайс закончил выполнение последней команды и можно посылать новую?

считаю количество шагов, на которое переместился привод: таймер работает в режиме СТС. регистр compare загружается соответствующим расчетным значением. в прерывании происходит команда step драйверу привода и соответственно счетчик шагов в инкремент. как досчитал до значения переданного в команде так стоп. вот вроде пояснил. если чего, спрашивайте

[defunct]

видно, что только в одном случае нельзя восстановить новую информацию, но сохраняется старая.

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

[smk]

Ионистор ставить не желаете? А вообще для таких условий STM8S лучше подойдет. EEPROM там зело быстрее.

[demaven]

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

[desh]

А что вам мешает защищать ваши ячейки контрольной суммой? Например так:

CODE

#include "crc.h"
#include "eeprom.h"

//******************************************************************************
// Функция сохраняет данные в еепром с добавлением 2 байт CRC
//******************************************************************************
bool SaveBlock(unsigned short Address, char* Data, unsigned short Size)
{
char Ch;
unsigned short Crc = 0xFFFF;

for (unsigned short Index = 0; Index < Size; Index++)
{
Ch = Data[Index];
__EEPUT(Address + Index, Ch);
Crc = AddCrc16(Ch, Crc);
}
__EEPUT(Address + Size, (unsigned char)Crc);
__EEPUT(Address + Size + 1, (unsigned char)(Crc >> 8));
return true;
}

//******************************************************************************
// Функция читает данные из еепром с контролем 2 байт CRC
//******************************************************************************
bool LoadBlock(unsigned short Address, char* Data, unsigned short Size)
{
char Ch;
unsigned short Crc = 0xFFFF;

for (unsigned short Index = 0; Index < Size; Index++)
{
__EEGET(Ch, Address + Index);
Data[Index] = Ch;
Crc = AddCrc16(Ch, Crc);
}
__EEGET(Ch, Address + Size);
Crc = AddCrc16(Ch, Crc);
__EEGET(Ch, Address + Size + 1);
Crc = AddCrc16(Ch, Crc);
return Crc ? false : true;
}

xSemaphoreHandle EepromLockMutex = NULL;

//******************************************************************************
// Заблокировать интерфейс
//******************************************************************************
void EepromLock()
{
portENTER_CRITICAL();
if(EepromLockMutex == NULL) EepromLockMutex = xSemaphoreCreateMutex();
portEXIT_CRITICAL();
xSemaphoreTake(EepromLockMutex, portMAX_DELAY);
}

//******************************************************************************
// Разблокировать интерфейс
//******************************************************************************
void EepromUnlock()
{
xSemaphoreGive(EepromLockMutex);
}

//******************************************************************************
// Функция загружает конфигурацию из EEPROM в случае успеха возвращает true
//******************************************************************************
bool EepromLoadConfig(USHORT Offset, void* Config, unsigned short Size)
{
bool Ret = true;

Offset = (Offset + 2) * 2;
EepromLock();
if (!LoadBlock(Offset + 0, Config, Size))
if (!LoadBlock(Offset + Size + 2, Config, Size))
Ret = false;
EepromUnlock();
return Ret;
}

//******************************************************************************
// Функция сохраняет конфигурацию в EEPROM в случае успеха возвращает true
//******************************************************************************
bool EepromSaveConfig(USHORT Offset, void* Config, unsigned short Size)
{
Offset = (Offset + 2) * 2;
EepromLock();
SaveBlock(Offset + 0, Config, Size);
SaveBlock(Offset + Size + 2, Config, Size);
EepromUnlock();
return true;
}

Функции EepromLock/EepromUnlock и расчет смещения для нескольких записей можно удалить. Функцию для расчета crc добавить по вкусу.

Сообщение отредактировал IgorKossak - Feb 27 2012, 14:37

Причина редактирования: [codebox]

[zombi]

с двумя местами сохранения никак не получается. ячейки неоднобайтовые

Если ячейки неоднобайтовые я называл бы их не ячейками а блоками...
И вполне можно обойтись всего двумя одинаковыми блоками если в каждый добавить ОДНОБАЙТОВЫЙ флаг (ноль/не ноль) достоверности блока.

P.S. Без всяких CRC.