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

[ArtDenis]

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

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

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

[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]

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

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

[AlexandrY]

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

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

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

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