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

[ArtDenis]

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

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

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

[RabidRabbit]

Самое простое - использовать в качестве ключа смещение данных в ЭППЗУ.

[alexeyv]

Самое простое - использовать в качестве ключа смещение данных в ЭППЗУ.

+100500

Код

typedef struct  __eepRecord__
{
    unsigned char*        Addr;        // адрес объекта в EEPROM
    unsigned char*        ram;            // адрес объекта в оперативке
    unsigned int        Size;            // размер объекта
} __attribute__ ((packed))  eepRecord;

eepRecord     eepBase[100500];

readRecord(eepRecord * Rec)
{
     eepRead(Rec->Addr,Rec->ram,Rec->Size);
}
writeRecord(eepRecord * Rec)
{
     eepRead(Rec->ram,Rec->Addr,Rec->Size);
}

Сообщение отредактировал alexeyv - Jun 10 2015, 03:08

[_Pasha]

ТС, Вы ничего не сказали об интенсивности стираний элементов. Потому что если у Вас пойдет сильная фрагментация, то доступ к объектам нужно делать через двойные указатели.

Сообщение отредактировал _Pasha - Jun 10 2015, 03:43

[ArtDenis]

Самое простое - использовать в качестве ключа смещение данных в ЭППЗУ.

+100500

Нет. Это не соответствует требованию "размер и количество которых заранее неизвестно". В качестве ключа я хочу выбирать число, которое как-то характеризует хранимые данные.

ТС, Вы ничего не сказали об интенсивности стираний элементов. Потому что если у Вас пойдет сильная фрагментация, то доступ к объектам нужно делать через двойные указатели.

Да, фрагментация будет конечно. Я хочу чтобы эту проблему решала сама библиотека.

Фактически, мне нужно от библиотеки что-то типа такого:

Код

#define CONFIG_KEY 1
#define DATA_KEY 2
#define SUPER_PUPER_KEY 0xFFFFFFFF
...
save_into_eeprom(CONFIG_KEY, &config, sizeof(config));
save_into_eeprom(DATA_KEY, &data, sizeof(data));
save_into_eeprom(SUPER_PUPER_KEY, &super_puper_value, sizeof(super_puper_value));
...
load_from_eeprom(CONFIG_KEY, &config, sizeof(config));
load_from_eeprom(DATA_KEY, &data, sizeof(data));
load_from_eeprom(SUPER_PUPER_KEY, &super_puper_value, sizeof(super_puper_value));
...
erase_key(SUPER_PUPER_KEY);

+ желательно чтобы можно было перечислять ключи записей, которые хранятся на данный момент.

Фактически, это должно быть что-то типа файловой системы, только в качестве имени файла выступает целое число.

[AlexandrY]

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

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

Так не делают. Это неудобно и негибко.
Делают так:
В паре Key=Value , Key - это строковый идентификатор, а Value - сериализированные данные, т.е. представленные тоже в виде строки.
Если действительно структура данных сложная и неизвестная, то применяют формат JSON, а данные хранятся в древовидных структурах.
Но файловую систему к этому не примешивают. Файловая система отдельно, а парсинг файлов отдельно.
Для EEPROM очень простая файловая система есть у Keil, она включает и дефрагментацию и равномерный износ в ней учитывается.

[ArtDenis]

Так не делают. Это неудобно и негибко.
Делают так:
В паре Key=Value , Key - это строковый идентификатор, а Value - сериализированные данные, т.е. представленные тоже в виде строки.

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

[AlexandrY]

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

Если интересует сжатие, то так прямо и спрашивайте.

[ArtDenis]

Если интересует сжатие, то так прямо и спрашивайте.

Какое ещё сжатие? Требования расписаны, пример того, что я хочу - есть. Сжатия среди требований нету. Откуда оно взялось?

[psL]

на самом деле в key-value данные хранятся по хешу key, т.е. по целому, а не по строке, а ТС предлагает вместо хеш-функции использовать перечисление.
Вообще непонятно зачем это в таком виде нужно, поскольку key-value используется для скоростной выборки данных, а тут всего 12кБ - т.е. можно просто последовательно перечитать весь носитель за миллисекунды. Хранить данные можно друг за другом, например в виде index, type, data, crc. Придумать случай, когда программа не знает размера структуры данных в eeprom затрудняюсь.
А так - есть всякие bson, protobuf и т.п., но это в данном случае наверное тяжело будет.

[RabidRabbit]

Так и почитайте о файловых системах, решение к Вам и придёт
Например, разбиваете Вашу ЭППЗУ на блоки равного размера.
Самый первый обзываете суперблоком и пишете туда размер одного блока, их количество, сколько свободных блоков осталось и ещё может что.
Следом в одном или нескольких блоках размещаете битовую карту занятых блоков (бит сброшен - блок занят).
Каждый блок состоит из номера следующего блока и данных.
В следующем после битовой карты блоке размещается каталог, содержащий записи вида: номер первого блока/размер информации.
Для добавления нового Value ищете первую свободную запись в каталоге, если нет, добавляете к каталогу ещё один блок.
Далее находите столько номеров свободных блоков, сколько требуется для размещения Value, записывается информацию в эти блоки, располагая их цепочкой, вносите изменения в битовую карту и суперблок. Ключом будет являтся номер первого блока в цепочке.
Для перечисления просматриваете каталог.
Удаление Value также не представляет сложности.

[ArtDenis]

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

Скорость для меня не важна. И требования я такого не ставил. Для меня главное, чтобы работа с данными производилась через целочисленный ключ. А идеология "Ключ->Значение" приведена в качестве примера чего я хочу.

Так и почитайте о файловых системах, решение к Вам и придёт

Я ищу готовый вариант. Свой велосипед я всегда успею написать

[esaulenka]

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

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

PS делали подобный велосипед (структура - прям по букварю); но там была флеш. При изменении настроек всё вычитывалось, перестраивалось и записывалось обратно; с фрагментацией бороться было не надо.

[AlexandrY]

Какое ещё сжатие? Требования расписаны, пример того, что я хочу - есть. Сжатия среди требований нету. Откуда оно взялось?

Не, требования свои оставьте себе.

А я пишу как делают, и что можно найти.
Так вот когда нужно работать с настройками применяют три отдельные вещи: парсинг файлов, сжатие файлов и файловую систему.
Пытаться уменьшить объем файла за счет применения цифр вместо строк это непрофессиональный стиль и никто так не лаж....

Хотя если найдете такое будет интересно.
Скорее всего вам надо к ардуинщикам.

[ArtDenis]

Не, требования свои оставьте себе.

Не-не, забираейте. Мне не жалко

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

Я нигде не говорил про работу с настройкам. Это ваши фантазии. Или меня с кем-то перепутали. Перечитайте первое сообщение в теме.

PS: и можно конкретную ссылку на реализацию того, о чём вы говорили.

Пытаться уменьшить объем файла за счет применения цифр вместо строк это непрофессиональный стиль и никто так не лаж....

Я не пытаюсь уменьшить объём. Это тоже ваши фантазии.
На стиль мне плевать. Мне надо решить задачу, а не строить из себя профессионала

Хотя если найдете такое будет интересно.
Скорее всего вам надо к ардуинщикам.

Буду рад конкретной ссылке как это реализовано у ардунинщиков.

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

[Эдди]

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

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

[ArtDenis]

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

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

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

[mcheb]

Предполагается в EEPROM хранить (и при необходимости читать) разные наборы данных, размер и количество которых заранее неизвестно.

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

[ar__systems]

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

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

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

[Сергей Борщ]

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

[AHTOXA]

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

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

[ViKo]

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

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

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

[Эдди]

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

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

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

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

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

[ArtDenis]

Пишете же вы! Как можно не знать, какой размер у данных будет?

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

фрагментация не проблема - при каждом стирании все подгребаете к началу.

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

[_Pasha]

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

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

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

[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

[zltigo]

Предполагается в EEPROM хранить (и при необходимости читать) разные наборы данных, размер и количество которых заранее неизвестно.

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

[jcxz]

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

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