> [57] NailMan ©   (29.01.17 20:11)
> старое затираю нулями.

В 2 раза ресурс меньше, чем со счётчиком.

> внутри есть сторожевик по питанию - если включен, его хватает
> чтобы eeprom не портилась

его назначение формирование сброса после установки питания.
это как это он умудряется защитить еепром от незавершения операции?

>  обычно больше 10-13 мин не летаю

менеджер записи ненужен вообще.

> [58] GEN++ ©   (29.01.17 22:07)
> >девайс может быть обесточен в любой момент
> этим моментом может быть запись в EEPROM после чего
> я бы не поручился что весь EEPROM не будет стерт
> Так что реши вопрос сначала с этим а уже потом как читать/писать,
>
> посмотри поиском на www.electronix.ru может что найдешь

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

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

Правильно, любая разработка это разрешение системы компромиссов.
Но, поверьте моему опыту, данное решение из серии худших.
Закон падающих кирпичей и бутербродов пока никто не отменял.

Здесь надо уметь задерживать падение питание устройства примерно на 50 мл сек по отношению к падению внешнего питания и уметь сообщать о "просадке" питания
контроллеру. Само Arduino nano c 19 mA потребления поддерживать на питании
не особо правильно.
IMHO - сделать в виде мезонина на базе ATtiny24/44/84 (0.3mA при тактовой 1 MHz)
внешнюю "умную" и защищенную от пропадания питания EEPROM (либо от ATtiny - 128 байт либо внешнюю). Кстати, при "износе" EEPROM мезонина легко текущий мезонин заменить на новый.

Связь с основным устройством по SPI либо аппаратному либо программному

> [64] GEN++ ©   (30.01.17 13:34)
> >Так как девайс имеет трехцветный светодиод с индикацией
> режимов, я могу на момент записи в еепром моргать ярким
> синим цветом, чтобы пользователь выключал в 10 сек промежуток.
>
> Правильно, любая разработка это разрешение системы компромиссов.
> Но, поверьте моему опыту, данное решение из серии худших.
> Закон падающих кирпичей и бутербродов пока никто не отменял.
>
> Здесь надо уметь задерживать падение питание устройства
> примерно на 50 мл сек по отношению к падению внешнего питания
> и уметь сообщать о "просадке" питания
> контроллеру. Само Arduino nano c 19 mA потребления поддерживать
> на питании
> не особо правильно.
> IMHO - сделать в виде мезонина на базе ATtiny24/44/84 (0.3mA
> при тактовой 1 MHz)
> внешнюю "умную" и защищенную от пропадания питания EEPROM
> (либо от ATtiny - 128 байт либо внешнюю). Кстати, при "износе"
> EEPROM мезонина легко текущий мезонин заменить на новый.
>
> Связь с основным устройством по SPI либо аппаратному либо
> программному

Весь девайс сейчас жрет до 372ма(при включенной сирене) и до 150ма при нормальном режиме. В целом можно типа такой бздюльки включить в состав железки
http://www.ebay.com/itm/0-047F-5-5V-Memory-Backup-Capacitor-Supercap-/152399363846

детектор наличия напряжения во входной сети - не вопрос, можно сбацать по типу как на старших ардуинах детектится и коммутируется питание между Vin/USB.

внешние eeprom есть у меня на i2c, на ARM32 контроллере чтобы тоже самое делать(конфиг держать и помнить потребление).

> kilkennycat ©   (30.01.17 07:36) [61]
>> внутри есть сторожевик по питанию - если включен, его хватает  чтобы eeprom не портилась

> его назначение формирование сброса после установки питания.

"для верности рекомендуют пользоваться аппноутом по ацп конкретного мк"


>  это как это он умудряется защитить еепром от незавершения операции?

не знаю, я такого не говорил.

> NoUser ©   (30.01.17 14:43) [66]

Ок. давай сначала уточним, что ты имеешь ввиду под "внутри сторожевик по питанию".

BOD (Brown-out Detection)
http://fusecalc.mirmk.ru/help/help04.htm

> NoUser ©   (31.01.17 13:23) [68]
> http://fusecalc.mirmk.ru/help/help04.htm

ну и где же тут аппноут ;)

Хорошо, уже лучше. стало ясно, какой именно сторожевик по питанию используется. И он по-прежнему формирует сигнал сброса.

NoUser ©   (30.01.17 00:11) [59]

>>девайс может быть обесточен в любой момент
> этим моментом может быть запись в EEPROM

внутри есть сторожевик по питанию - если включен, его хватает чтобы eeprom не портилась,

NoUser ©   (30.01.17 14:43) [66]
>  это как это он умудряется защитить еепром от незавершения операции?

не знаю, я такого не говорил.

Нет никаких противоречий?

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

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

Спасибо всем за участие в главной теме, реализовал менеджер с постоянным адресом

поле для данных 480байт. в пределах заголовка хранятся 2 байта под адрес. Также есть в памяти счетчик дампов, который каждую сессию начинается с начала.

В начале, при инициализации, читаю адрес размещения записи, читаю запись по адресу, сразу увеличиваю адрес +4(сохраняю этот адрес в eeprom) и начинаю цикл.
Каждые 10 сек происходит дамп значения мА в eeprom по текущему адресу, спустя 50 циклов увеличиваю адрес +4, сохраняю его, зануляю счетчик дампов и все начинается заново.

Место куда пишется адрес изменяется в 50 раз реже чем дамп. Если я включаю девайс на короткое время(менее чем на 500сек), он сразу сместит адрес для дампа, освежив позицию.

на время пока идет дамп(короткий только значения мА или полный с перезаписью адреса) я моргаю свободной лампочкой. В третьей версии платы я реализую бэкап ардуины с помощью переключателя входного питания и суперконденсатора на 0.33F. Этого должно хватить на дамп и "корректное закрытие". Потом это пригодится на полном контроллере, где придется еще закрывать запись на карту SD.

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

> NoUser ©   (01.02.17 20:19) [70]

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

> [72] kilkennycat ©   (02.02.17 03:02)
>
> > NoUser ©   (01.02.17 20:19) [70]
>
> предположим, запись уже началась, то есть идет выполнение
> команды (это не моментальный процесс), и посреди его питание
> стало нулем.

сразу нулем не станет, так как на реальных девайсах есть:
1) сглаживающие емости 10-47мкФ на выходе регулятора питания 5В
2) комплексный С-фильтр(1-0.1-0.01мкФ) непосредственно у самого девайса( и еще у самого МК).

Эти емкости поддержат какое то время напряжение в силу своей инерциальности и накопленного заряда.

> NailMan ©   (02.02.17 10:50) [73]
Эти емкости поддержат какое то время напряжение в силу своей инерциальности и накопленного заряда.

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

Это, конечно, грубые подсчеты. Но думаю, подсчет точного энергопотребления и потерь  еще сильней испортит картину.

> NailMan ©  

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

сделал замер времени выполнения таймерного(каждые 250мс) обработчика где математика идет - тот проход(раз в сек) на котором математика по всем событиям считается выполняется за 25.6мс. Если в этот проход попадает дамп потребления в еепром - 35.6мс, в остальные проходы(когда проходы холостые) - 200мкс.

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

Сделал обнуление счетчика максимального количества пакетов не в таймерном обработчике, а в обработчике аппаратного прерывания через внешний флаг, который в таймерном присваиваю true, когда надо обнулить. При этом даже откючал прерывание на время этого присваивания, а потом включал - все равно идет провал. была мысля что в обработчике прерывания переменная увеличивается 50раз в секунду и в какой то момент попадает на момент обнуления в таймерном обработчике и получается что сброс гадит счетчику. Но получается что косяк в чет то другом.

>kilkennycat
>нет гарантии что он начнет разряжаться прямо перед записью,

В Десятку!!....!!
Повторюсь: пока не будет надежно защищен процесс записи
в EEPROM, разработка ПО будет по принципу "хотели как лучше, а получилось-
как получилось"

> [77] GEN++ ©   (02.02.17 19:40)
> Повторюсь: пока не будет надежно защищен процесс записи
> в EEPROM

Все будет в материнской плате v3.0. Суперкап на 0.2-0.33Ф на 5.5В. Чтоб заряжался минуты 3-4 пока на земле проходит проверки. Поддерживать должон дофига времени. Задетектит пропадание входного питания и завершит запись и перестанет дампить. далее отключение будет безопасным.

Если так заморачиваться с надежностью, то всё-таки и еепром надо внешнюю или вообще, как говорил выше GEN++, отдельный логгер.