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

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

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

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

+100500



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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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


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

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