[Eddy_Em 1]

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

Как только писать уже некуда, стираем страницу и начинаем писать с начала.

Если после резета видим в самом начале нуль, то пользуем дефолтные настройки, т.к. EEPROM пуста.

 

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

[ArtDenis 0]

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

 

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

Изменено 10 июня, 2015 пользователем ArtDenis

[mcheb 0]

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

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

[slavka012 0]

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

 

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

 

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

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

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

[AHTOXA 15]

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

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

[ViKo 1]

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

При стирании перемещать записи на свободное место, корректировать номер и смещение.

 

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

 

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

[Eddy_Em 1]

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

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

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

 

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

 

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

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

[ArtDenis 0]

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

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

 

 

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

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

 

[_Pasha 0]

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

 

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

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

[jcxz 192]

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

При стирании перемещать записи на свободное место, корректировать номер и смещение.

Таблица не нужна.

Создаём обычный журнал: длина записи - переменная, имеется фикс. заголовок, после которого - пользовательские данные переменной длины указанной в заголовке;

в заголовке также указан ID записи (а также CRC и т.п. по желанию). В заголовке есть флажок валидности записи (1 бит).

Новые записи добавляются в конец журнала. Для чтения записи с конца журнала ищется первый попавшийся ID равный нужному. При добавлении записи с ID, который уже есть в журнале,

в заголовке старой записи снимается флажок валидности (set 0). В новой записи флаг валидности set 1 (если стёртое состояние флешь == 1).

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

 

Такой алгоритм можно использовать и на флешь (где доступ по стиранию поблочный, а не байтовый). Чем больше объём использумой под журнал флешь - тем лучше - меньше износ.

Для ускорения поиска в ОЗУ можно хранить таблицу соответствия номеров записей журнала определённым ID. Создавать её при старте ПО, обновлять при добавлении записей в журнал.

[jenya7 0]

Таблица не нужна.

Создаём обычный журнал: длина записи - переменная, имеется фикс. заголовок, после которого - пользовательские данные переменной длины указанной в заголовке;

в заголовке также указан ID записи (а также CRC и т.п. по желанию). В заголовке есть флажок валидности записи (1 бит).

Новые записи добавляются в конец журнала. Для чтения записи с конца журнала ищется первый попавшийся ID равный нужному. При добавлении записи с ID, который уже есть в журнале,

в заголовке старой записи снимается флажок валидности (set 0). В новой записи флаг валидности set 1 (если стёртое состояние флешь == 1).

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

 

Такой алгоритм можно использовать и на флешь (где доступ по стиранию поблочный, а не байтовый). Чем больше объём использумой под журнал флешь - тем лучше - меньше износ.

Для ускорения поиска в ОЗУ можно хранить таблицу соответствия номеров записей журнала определённым ID. Создавать её при старте ПО, обновлять при добавлении записей в журнал.

 

а адресс заголовка где храниться?

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

нет что то не вяжется. вобщем как ни крути а надо создавать что то вроде а ля фат.

Изменено 14 июня, 2015 пользователем Jenya7

[zltigo 1]

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

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

 

[jcxz 192]

а адресс заголовка где храниться?

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

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