Чтобы пореже стирать EEPROM, мне как-то предлагали такой вариант: после резета сканируем содержимое EEPROM с инкрементом, равным размеру нашей структуры; как только натыкаемся на ноль, откатываем назад -- вот она, последняя! Для записи, соответственно, прыгаем в перед и пишем.
Как только писать уже некуда, стираем страницу и начинаем писать с начала.
Если после резета видим в самом начале нуль, то пользуем дефолтные настройки, т.к. EEPROM пуста.

Правда, я такую схему еще не реализовал. Но надо будет, особенно для STM32, у которых только флеш, а EEPROM'а нет.

Эдди, спасибо за идею! Хотя у меня есть подозрение, что она подходит только для записи структуры фиксированного размера.

PS: как это у STM32 нету EEPROM? Ещё как есть. Надо только правильную серию выбрать

Сообщение отредактировал ArtDenis - Jun 10 2015, 09:48

Смотрите в сторону дескрипторов в USB

А че так сложно-то все? Данных всего - каких-то жалких 12 килобайт, а в требованиях - чуть ли не база данных или файловая система.

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

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

Гляньте minIni. Это не совсем то, что вам нужно - это библиотека работы с ini-файлами поверх файловой системы. Но если в ней заменить строки ключей на enum и прописать свои функции доступа к eeprom вместо функций доступа к файлам - можно сделать достаточно близко к тому, что вы хотите. Она занимает совсем немного места и подправить ее не должно состоавить труда. Во всяком случае ее можно использовать как отправную точку.

+1. Просто и надёжно.

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

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

ЗЗЫ. Номер не нужен, он однозначно определяется местом в таблице (или нет?).

Пишете же вы! Как можно не знать, какой размер у данных будет?
Если же действительно имя и содержимое выдумывает пользователь, то нечего морочить себе и людям голову! Подключайте флешку и пишите на ней либо полноценную ФС, либо БД вроде кастрированной sqlite.

С другой стороны, здесь уже упоминали формат JSON — почему бы не использовать его для сериализации хранимых данных? Один только косяк — удалять ненужные данные будет крайне сложно и долго. Однако, и здесь можно выход найти: в отдельном блоке флеш или eeprom сохранять имена структур, нонче уже потерявших актуальность. Ну, а как писать уже некуда будет, все подчищать.


EEPROM есть только в дорогущих lite-сериях. В дешевой попсе его нет, к сожалению.

Я имею ввиду, что ваш способ подходит для записей большого количества структур одинакового размера. Или я ошибаюсь?



Не совсем понятно что имеется ввиду под "все подгребаете к началу"

+1 Номер не нужен. Размер может и не нужен, если есть время на сортировку и подсчеты оного. Только таблица указателей. Износ оной вроде как такой же как и информационной остальной части.

Таблица не нужна.
Создаём обычный журнал: длина записи - переменная, имеется фикс. заголовок, после которого - пользовательские данные переменной длины указанной в заголовке;
в заголовке также указан ID записи (а также CRC и т.п. по желанию). В заголовке есть флажок валидности записи (1 бит).
Новые записи добавляются в конец журнала. Для чтения записи с конца журнала ищется первый попавшийся ID равный нужному. При добавлении записи с ID, который уже есть в журнале,
в заголовке старой записи снимается флажок валидности (set 0). В новой записи флаг валидности set 1 (если стёртое состояние флешь == 1).
При налезании текущего хвоста журнала на его голову, анализируем какие записи в затирамеой части остались валидны, их перезаписываем в хвост.

Такой алгоритм можно использовать и на флешь (где доступ по стиранию поблочный, а не байтовый). Чем больше объём использумой под журнал флешь - тем лучше - меньше износ.
Для ускорения поиска в ОЗУ можно хранить таблицу соответствия номеров записей журнала определённым ID. Создавать её при старте ПО, обновлять при добавлении записей в журнал.

а адресс заголовка где храниться?
а понял. то есть если я хочу найти 10-ю запись я должен просуммировать 9 размеров + офсет?
нет что то не вяжется. вобщем как ни крути а надо создавать что то вроде а ля фат.

Сообщение отредактировал Jenya7 - Jun 14 2015, 05:52

В основе все на самом деле просто - храните конфигурацию в текстовом виде. Разборка структурированного текста на параметры совершенно не сложна. Гибкость - экстремальная.

Заголовок - это часть записи. Всё остальное в записи - полезные данные. Журнал состоит из некоторого целого кол-ва записей.