Циклический буфер переменной длины

RY723 · 31.10.2010, 16:05

Извиняюсь. Я имел ввиду пост №8 и EEPROM соответственно. Речь-то шла про кольцевой буфер. А во FLASH это невозможно. Там запись производится страницами. "Кольцо" можно сделать только сегментированным.
Хотя я здесь и не прав. Взять для примера AT45DB161D. Стирание возможно постраничное, а вот про запись - не помню. Но в этом случае ресурс FLASH-памяти гораздо выше чем у EEPROM. И правило соблюдается - снаряд два раза в одно место не попадает. Ведь записи всякий раз другой длины? А если они одиноаковой длины, то можно рассчитать (добавив несколько пустых записей 0xFF), чтобы маркер постоянно смещался, не попадая в одно и тоже место. Емкость этой м/с - около 4000 страниц по 512/528(? не помню уже) байт.
Во всяком случае, там можно заносить данные сначала в буфер (буфера два), а лишь потом переписать во FLASH.

аtаs_stas · 31.10.2010, 16:22

Сообщение от asket76

Мне дали задание для микроконтроллера (не важен какой, главное, алгоритм) написать циклический буфер переменной длины, равномерно распределенный по всей памяти (NAND Flash или EEPROM), чтоб исключить перезапись в одну и ту же область памяти из за их ограничения числа записи-стирания.

Посмотрите апликуху от Микрочип "Использование FLASH памяти в качестве EEPROM".

asket76 · 31.10.2010, 16:26

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

picavr · 31.10.2010, 19:45

Сообщение от RY723

Это не совсем точно - наряд два раза в одно место не попадает.

Маркер переписывается ДВА РАЗА. 1 - актуально 2- неактуально. А данные только ОДИН РАЗ. А вот если следующее сообщение накладывать на маркер предыдущего...

RY723 · 31.10.2010, 19:57

Сообщение от picavr

Маркер переписывается ДВА РАЗА. 1 - актуально 2- неактуально. А данные только ОДИН РАЗ

Упустил.

Тогда надо иметь два маркера. Один маркер - маркер, второй маркер должен иметь значение 0xFF. Вместо переписывания первого маркера, переписывается маркер со значением 0xFF. Вот тогда рксурс точно не пострадает.

asket76 · 31.10.2010, 22:40

Сообщение от RY723

Тогда надо иметь два маркера. Один маркер - маркер, второй маркер должен иметь значение 0xFF. Вместо переписывания первого маркера, переписывается маркер со значением 0xFF. Вот тогда рксурс точно не пострадает.

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

RY723 · 31.10.2010, 22:49

Сообщение от asket76

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

Ну как нет? Делаете запись пакетом:

Маркер1, Место под маркер два (0xFF), Размер данных, CRC

Этих данных достаточно, чтобы отличить вашу запись от мусора.
При расчёте CRC, заменяйте Маркер2 на 0xFF.

Даже если совпадёт мусор с маркерами, остаются данные по длине и CRC.

Это позволит однозначно идентифицировать данные. А маркеры можете сделать и длиннее. Не обязательно по одному байту. Так от случайного совпадения маркеров с мусором, защита будет ещё сильнее.

Обязательно сделайте так, чтобы исключить возможность попадания нового пакета на старое место. Т.е. количество записей в кольце не должно быть целым, тогда новая запись будет надёжно затирать старую. FLASH перед записью должна стираться. Если затирать не одну страницу перед записью, а допустим, две-три, тогда у вас вообще проблем не будет с поиском. Ищите чистое место и начинаете с "хвоста" искать маркер с проверкой условий целостности данных.