Хранилище "Key->Value" для EEPROM Опции

[ArtDenis]

Предполагается в EEPROM хранить (и при необходимости читать) разные наборы данных, размер и количество которых заранее неизвестно. На мой взгляд для этого подходит идеология хранилища Key->Value, где Key - это например целое число, по которому я идентифицирую сохраняемый набор, а Value - данные этого набора в бинарном виде. Есть ли готовые библиотеки для подобных хранилищ, для которых надо было бы дописать только чтение/запись EEPROM?

PS: размер EEPROM небольшой - всего 12 Кб. Размер сохраняемых наборов - от нескольких байт до килобайта.

Сообщение отредактировал ArtDenis - Jun 9 2015, 12:15

[ViKo]

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

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

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

[jcxz]

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

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

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

[Jenya7]

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

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

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

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