Салют камрады!

Нужен совет по написанию маленького менеджера памяти для EEPROM на ардуине (AVR), если конкретно то Nano. не реализация в коде, а сама идея.

Задача:
Есть девайс на Arduino Nano, в которой встроенный в МК EEPROM емкостью 512 байт в первых 32 байтах хранит конфиг девайса(почти статичен), а остальное пространство отдается под хранение динамических данных.
Ресурс у EEPROM ограничен в 100тыс перезаписей.

Девайс замеряет потребление энергии и сохраняет съеденное в переменную S длиной 4 байта. Необходимо раз в 10 сек дампить эти 4 байта съеденных миллиамперов в EEPROM так как девайс может быть обесточен в любой момент, а продолжать считать съеденное должен с последней сохраненной записи, а не с нуля.

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

Думал писать в пределы конфига(там есть еще место) адрес расположения созраняемого числа и периодически его менять используя счетчик, который также сохранять в пределах конфига. Типа каждые 10-20 включений контроллера(каждый раз он будет сохранять значение счетчика в eeprom при включении) будет рандомно меняться адрес размещения сохраняемого числа и записываться в другие 4 ячейки. Но тогда будет изнашиваться место размещения счетчика.

Может есть какие то более красивые реализации подобного менеджера? мож кто сталкивался?

4 байта каждые 10 сек = 24 байта в минуту = 1440 в час
то есть за час все успеет перезатереться три раза

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

но так как нужны часы, а часам нужны ноги, то проще сразу прикрутить внешнюю флешку.

> [1] rrrrr ©   (27.01.17 23:24)
> 4 байта каждые 10 сек = 24 байта в минуту = 1440 в час
> то есть за час все успеет перезатереться три раза
>
> отказываемся от запоминания адреса хвоста,
> добавляем rtc и замешиваем текущую позицию для записи чтения
> на текущем времени внутри текущего часа.
>
> но так как нужны часы, а часам нужны ноги, то проще сразу
> прикрутить внешнюю флешку.

Не, девайс уже собран, RTC некуда ему цеплять уже ни по ногам, ни по габаритам и памяти для бибилиотеки RTC мало, уже 70% использовано, а при 75+ он уже ругается что может глючить(ведь там ОЗУ неявно еще используются по всякие динамические выделения)

Записывай счётчик вместе с байтом. Только помнится мне... Как там EEPROM организована? - эти байты ведь строками пишутся, так что в пределах строки разницы нет куда писать, ну и ресурс надо разделить где-то на 16. Я не прав?

> [3] Inovet ©   (28.01.17 00:13)
> Записывай счётчик вместе с байтом. Только помнится мне...
> Как там EEPROM организована? - эти байты ведь строками пишутся,
> так что в пределах строки разницы нет куда писать, ну и
> ресурс надо разделить где-то на 16. Я не прав?

Не, в eeprom AVR пишется все побайтно. на внешних eeprom(на ARM32 ардуине предстоит тоже самое делать) через i2c вроде блочно(строками) пишется, пока не ковырялся. Пока бы в простом варианте осилить.

Ну тогда после старта ищем в памяти максимальное значение счётчика - это и будет последняя запись, следующие записи сохраняем в следующие ячейки с увеличением счётчика. Только при поиске последней записи по максимальному значению счётчика, смотрим переход на 0, если в следующей записи что-то больше 0, значит текущая последняя. Размер счётчика надо сделать 6 бит.

> [5] Inovet ©   (28.01.17 00:45)
> 6 бит.

10

Я тоже парился этой темой, в итоге sd карту припаял и писал в нее невзирая на ФС. Гораздо больше пространства для маневра.

Ну а так самое просто что прихошло мне тогда:
Зануляешь пространство. Пришешь счет в любое место. Когда считаешь, что настало время (раз в сто обновлений, например) смещаешь счет (случайно, но можно для гарантии равномерности на 1 байт), а предыдущий зануляешь.

+ Можно припаять емкость к питанию и отслеживать пропадание внешнего питания и писать только при его прекращении. У меня да этого руки не дошли, бизнес распался (

> [8] DayGaykin ©   (28.01.17 09:18)
> Ну а так самое просто что прихошло мне тогда:
> Зануляешь пространство. Пришешь счет в любое место. Когда
> считаешь, что настало время (раз в сто обновлений, например)
> смещаешь счет (случайно, но можно для гарантии равномерности
> на 1 байт), а предыдущий зануляешь.
>
> + Можно припаять емкость к питанию и отслеживать пропадание
> внешнего питания и писать только при его прекращении. У
> меня да этого руки не дошли, бизнес распался (

Тоже думал о "бесперебойнике", даже купил готовый модуль для этого - маленькая бздюлька с microusb для зарядки, просто usb для питания устройств и парой деталек бустера/зарядника и контакты под припайку LiOn батарейки 18650 или другого формфактора. Модуль для создания простейшего повербанка. Вместо разъема ЮСб проводами ардуину питать. Но бустер дает такие пульсации что измерение напряжения невозможно точное(а оно нужно). Потому отказался.
С емкостями тут не пойдет - надо суперкап для того чтобы напряжение нужное держалось. Да и девайс сильно усложнять и удорожать сильно(проект открытый вобщем то).

Попробую пару способов тогда.

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

перелезать на arm
1. чипы как минимум не дороже
2. больше рама, больше ног, больше периферии.

3. проще разрабатывать

> Ресурс у EEPROM ограничен в 100тыс перезаписей.

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

перепутал нули :) да, сотня тысяч для встроенной норма.

а менеджер простой.
перебираешь в цикле чтением все адреса по порядку, пока не встретится 0. по этому адресу пишешь новые данные, по адресу+1 записываешь 0. если адреса кончились, а 0 не вернулся - запись с начального адреса. если адрес+1 вылез за диапазон - запись 0 в начальный адрес.
Итого: имеем запись по кругу, возможность чтения истории за некий период.

> [10] rrrrr ©   (28.01.17 12:12)
> перелезать на arm
> 1. чипы как минимум не дороже
> 2. больше рама, больше ног, больше периферии.

На АРМ я перейду, точнее это будет контроллер как развитие нынешнего. Нынешний девайс нужен для простой вещи - глушить бензиновый двигатель удаленно с пульта, определять не пропала ли связь пульта и приемника, следить за напряжением и расходом АКБ и включать поисковую сирену. На АРМ будет уже концепция IoT и все будет передаваться в облако, плюс еще стопицот функций и снимаемых параметров с датчиков на модели. Но размеры ардуины с ARM слишком большие для простых функций. Кроме того у АРМ нет своего EEPROm - он там палюбас внешний. Для этого у меня есть модуль i2c c RTC и EEPROМ совмещенный.

Мне Nano ардуинки для нынешнего девайся - за глаза совершенно. Проект предназначен для свободного повторения любым имеющим навыки ЛУТа и умением держать паяльник.


> перебираешь в цикле чтением все адреса по порядку, пока
> не встретится 0. по этому адресу пишешь новые данные, по
> адресу+1 записываешь 0. если адреса кончились, а 0 не вернулся
> - запись с начального адреса. если адрес+1 вылез за диапазон
> - запись 0 в начальный адрес.
> Итого: имеем запись по кругу, возможность чтения истории
> за некий период.

Вот наверно так и буду реализовывать. Правда чтение всего eeprom побайтно медленновато, несколько секунд.

Считываешь адрес счётчика.
Пишешь по этому адресу.
Читаешь по этому адресу.
Если запись-чтение не идентичны -
меняешь адрес счётчика и повторяешь процедуру

как замена RTC - кварц 32к прямо на ноги асинхронного таймера меги.
( питание от батарейки через диод и переход в powerdown по снижению питания )

> Правда чтение всего eeprom побайтно медленновато

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

> NoUser ©   (28.01.17 13:40) [17]

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