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

PS: размер EEPROM небольшой - всего 12 Кб. Размер сохраняемых наборов - от нескольких байт до килобайта.
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);
}
_Pasha
ТС, Вы ничего не сказали об интенсивности стираний элементов. Потому что если у Вас пойдет сильная фрагментация, то доступ к объектам нужно делать через двойные указатели.
ArtDenis
Цитата(RabidRabbit @ Jun 9 2015, 23:26) *
Самое простое - использовать в качестве ключа смещение данных в ЭППЗУ.

Цитата(alexeyv @ Jun 10 2015, 08:05) *
+100500

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

Цитата(_Pasha @ Jun 10 2015, 08:42) *
ТС, Вы ничего не сказали об интенсивности стираний элементов. Потому что если у Вас пойдет сильная фрагментация, то доступ к объектам нужно делать через двойные указатели.

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

Фактически, мне нужно от библиотеки что-то типа такого:
Код
#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
Цитата(ArtDenis @ Jun 9 2015, 15:14) *
Предполагается в EEPROM хранить (и при необходимости читать) разные наборы данных, размер и количество которых заранее неизвестно. На мой взгляд для этого подходит идеология хранилища Key->Value, где Key - это например целое число, по которому я идентифицирую сохраняемый набор, а Value - данные этого набора в бинарном виде. Есть ли готовые библиотеки для подобных хранилищ, для которых надо было бы дописать только чтение/запись EEPROM?

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


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


Я не совсем понял, почему хранить данные по ключу, который представляет из себя целое значение это - "неудобно и негибко", и почему их надо хранить по строковому ключу да ещё в строковом виде? Зачем расходовать лишний EEPROM?
AlexandrY
Цитата(ArtDenis @ Jun 10 2015, 08:15) *
Я не совсем понял, почему хранить данные по ключу, который представляет из себя целое значение это - "неудобно и негибко", и почему их надо хранить по строковому ключу да ещё в строковом виде? Зачем расходовать лишний EEPROM?


Если интересует сжатие, то так прямо и спрашивайте.
ArtDenis
Цитата(AlexandrY @ Jun 10 2015, 10:31) *
Если интересует сжатие, то так прямо и спрашивайте.

Какое ещё сжатие? Требования расписаны, пример того, что я хочу - есть. Сжатия среди требований нету. Откуда оно взялось?
psL
на самом деле в key-value данные хранятся по хешу key, т.е. по целому, а не по строке, а ТС предлагает вместо хеш-функции использовать перечисление.
Вообще непонятно зачем это в таком виде нужно, поскольку key-value используется для скоростной выборки данных, а тут всего 12кБ - т.е. можно просто последовательно перечитать весь носитель за миллисекунды. Хранить данные можно друг за другом, например в виде index, type, data, crc. Придумать случай, когда программа не знает размера структуры данных в eeprom затрудняюсь.
А так - есть всякие bson, protobuf и т.п., но это в данном случае наверное тяжело будет.
RabidRabbit
Так и почитайте о файловых системах, решение к Вам и придёт sm.gif
Например, разбиваете Вашу ЭППЗУ на блоки равного размера.
Самый первый обзываете суперблоком и пишете туда размер одного блока, их количество, сколько свободных блоков осталось и ещё может что.
Следом в одном или нескольких блоках размещаете битовую карту занятых блоков (бит сброшен - блок занят).
Каждый блок состоит из номера следующего блока и данных.
В следующем после битовой карты блоке размещается каталог, содержащий записи вида: номер первого блока/размер информации.
Для добавления нового Value ищете первую свободную запись в каталоге, если нет, добавляете к каталогу ещё один блок.
Далее находите столько номеров свободных блоков, сколько требуется для размещения Value, записывается информацию в эти блоки, располагая их цепочкой, вносите изменения в битовую карту и суперблок. Ключом будет являтся номер первого блока в цепочке.
Для перечисления просматриваете каталог.
Удаление Value также не представляет сложности.
ArtDenis
Цитата(psL @ Jun 10 2015, 10:40) *
на самом деле в key-value данные хранятся по хешу key, т.е. по целому, а не по строке, а ТС предлагает вместо хеш-функции использовать перечисление.
Вообще непонятно зачем это в таком виде нужно, поскольку key-value используется для скоростной выборки данных

Скорость для меня не важна. И требования я такого не ставил. Для меня главное, чтобы работа с данными производилась через целочисленный ключ. А идеология "Ключ->Значение" приведена в качестве примера чего я хочу.
Цитата(RabidRabbit @ Jun 10 2015, 10:42) *
Так и почитайте о файловых системах, решение к Вам и придёт sm.gif

Я ищу готовый вариант. Свой велосипед я всегда успею написать biggrin.gif
esaulenka
Цитата(psL @ Jun 10 2015, 08:40) *
Придумать случай, когда программа не знает размера структуры данных в eeprom затрудняюсь.

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

PS делали подобный велосипед (структура - прям по букварю); но там была флеш. При изменении настроек всё вычитывалось, перестраивалось и записывалось обратно; с фрагментацией бороться было не надо.
AlexandrY
Цитата(ArtDenis @ Jun 10 2015, 08:37) *
Какое ещё сжатие? Требования расписаны, пример того, что я хочу - есть. Сжатия среди требований нету. Откуда оно взялось?


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

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

Хотя если найдете такое будет интересно.
Скорее всего вам надо к ардуинщикам.
ArtDenis
Цитата(AlexandrY @ Jun 10 2015, 12:17) *
Не, требования свои оставьте себе.

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

Цитата(AlexandrY @ Jun 10 2015, 12:17) *
А я пишу как делают, и что можно найти.
Так вот когда нужно работать с настройками применяют три отдельные вещи: парсинг файлов, сжатие файлов и файловую систему.

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

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

Цитата(AlexandrY @ Jun 10 2015, 12:17) *
Пытаться уменьшить объем файла за счет применения цифр вместо строк это непрофессиональный стиль и никто так не лаж....

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

Цитата(AlexandrY @ Jun 10 2015, 12:17) *
Хотя если найдете такое будет интересно.
Скорее всего вам надо к ардуинщикам.

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

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

PS: как это у STM32 нету EEPROM? Ещё как есть. Надо только правильную серию выбрать wink.gif
mcheb
Цитата(ArtDenis @ Jun 9 2015, 15:14) *
Предполагается в EEPROM хранить (и при необходимости читать) разные наборы данных, размер и количество которых заранее неизвестно.

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

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

Библиотека для этого никакая не нужна т.к. писанины на час макс. больше времени уйдет на поиск либы и разборки с ней.
Сергей Борщ
Гляньте minIni. Это не совсем то, что вам нужно - это библиотека работы с ini-файлами поверх файловой системы. Но если в ней заменить строки ключей на enum и прописать свои функции доступа к eeprom вместо функций доступа к файлам - можно сделать достаточно близко к тому, что вы хотите. Она занимает совсем немного места и подправить ее не должно состоавить труда. Во всяком случае ее можно использовать как отправную точку.
AHTOXA
Цитата(ar__systems @ Jun 10 2015, 15:17) *
Сделайте одну запись в виде размера за которой следует ваш ключ и соответсвуюещее кол-во байт данных, и отдельно храните общее кол-во записей. Если к скорости стирания нет требования, фрагментация не проблема - при каждом стирании все подгребаете к началу.

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

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

ЗЗЫ. Номер не нужен, он однозначно определяется местом в таблице (или нет?).
Эдди
Цитата(ArtDenis @ Jun 10 2015, 12:47) *
Эдди, спасибо за идею! Хотя у меня есть подозрение, что она подходит только для записи структуры фиксированного размера.

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

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

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

EEPROM есть только в дорогущих lite-сериях. В дешевой попсе его нет, к сожалению.
ArtDenis
Цитата(Эдди @ Jun 11 2015, 09:31) *
Пишете же вы! Как можно не знать, какой размер у данных будет?

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


Цитата(ar__systems @ Jun 10 2015, 15:17) *
фрагментация не проблема - при каждом стирании все подгребаете к началу.

Не совсем понятно что имеется ввиду под "все подгребаете к началу"
_Pasha
Цитата(ViKo @ Jun 11 2015, 07:09) *
ЗЫ. Таблицу разместить в конце памяти, и чтобы она росла к началу памяти. Тогда можно забить память до последнего байта... rolleyes.gif

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

+1 Номер не нужен. Размер может и не нужен, если есть время на сортировку и подсчеты оного. Только таблица указателей. Износ оной вроде как такой же как и информационной остальной части.
jcxz
Цитата(ViKo @ Jun 11 2015, 10:09) *
В начале EEPROM создать таблицу, в которой хранить номер-идентификатор (если он нужен), смещение в памяти (чтобы не складывать все размеры при поиске), размер записи. Дальше размещать сами записи.
При стирании перемещать записи на свободное место, корректировать номер и смещение.

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

Такой алгоритм можно использовать и на флешь (где доступ по стиранию поблочный, а не байтовый). Чем больше объём использумой под журнал флешь - тем лучше - меньше износ.
Для ускорения поиска в ОЗУ можно хранить таблицу соответствия номеров записей журнала определённым ID. Создавать её при старте ПО, обновлять при добавлении записей в журнал.
Jenya7
Цитата(jcxz @ Jun 13 2015, 11:02) *
Таблица не нужна.
Создаём обычный журнал: длина записи - переменная, имеется фикс. заголовок, после которого - пользовательские данные переменной длины указанной в заголовке;
в заголовке также указан ID записи (а также CRC и т.п. по желанию). В заголовке есть флажок валидности записи (1 бит).
Новые записи добавляются в конец журнала. Для чтения записи с конца журнала ищется первый попавшийся ID равный нужному. При добавлении записи с ID, который уже есть в журнале,
в заголовке старой записи снимается флажок валидности (set 0). В новой записи флаг валидности set 1 (если стёртое состояние флешь == 1).
При налезании текущего хвоста журнала на его голову, анализируем какие записи в затирамеой части остались валидны, их перезаписываем в хвост.

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


а адресс заголовка где храниться?
а понял. то есть если я хочу найти 10-ю запись я должен просуммировать 9 размеров + офсет?
нет что то не вяжется. вобщем как ни крути а надо создавать что то вроде а ля фат.
zltigo
QUOTE (ArtDenis @ Jun 9 2015, 15:14) *
Предполагается в EEPROM хранить (и при необходимости читать) разные наборы данных, размер и количество которых заранее неизвестно.

В основе все на самом деле просто - храните конфигурацию в текстовом виде. Разборка структурированного текста на параметры совершенно не сложна. Гибкость - экстремальная.
jcxz
Цитата(Jenya7 @ Jun 14 2015, 11:39) *
а адресс заголовка где храниться?
а понял. то есть если я хочу найти 10-ю запись я должен просуммировать 9 размеров + офсет?

Заголовок - это часть записи. Всё остальное в записи - полезные данные. Журнал состоит из некоторого целого кол-ва записей.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.