Хранение файлов на at45db, DataFlash + мк с малыми ресурсами. Как? Опции

[alcosar]

Предлагаю поделится опытом работы с DataFlash. А именно, как организовать на ней хранение файлов -- что-то вроде файловой системы? Какой оптимальный способ для микроконтроллера с малыми ресурсами(ОЗУ - 128..512 байт; FLASH - 2..16 килобайт)? Прилагаю файл с описанием того, как этот вопрос я решил для себя. Интересно ваше мнение, предложения и критика.

Прикрепленные файлы

 files_on_data_flash.zip ( 2.48 килобайт ) Кол-во скачиваний: 209

 

[alcosar]

Сам ФАТ нужно хранить в ОЗУ либо мк, либо DataFlash. В мк мало ОЗУ. В DataFlash во время записи используются оба буфера, чтобы ускорить запись. Сам ФАТ во флеши хранится в одной и той же странице. Т.е. запись в нее будет происходить при всякой операции записи. Нет равномерного износа.
Может можно сделать по-другому?
Исходники уже есть.

[kada]

Сам ФАТ нужно хранить в ОЗУ либо мк, либо DataFlash. В мк мало ОЗУ. В DataFlash во время записи используются оба буфера, чтобы ускорить запись. Сам ФАТ во флеши хранится в одной и той же странице. Т.е. запись в нее будет происходить при всякой операции записи. Нет равномерного износа.
Может можно сделать по-другому?
Исходники уже есть.

Выделить несколько страниц для хранения FAT и тем самым создать круговой буфер. В начале FAT предусмотреть некий маркер, по которому можно определить что данная страница содержит в себе валидную FAT. Для чтения из FAT находится страница с маркером. Для записи новой информации в FAT копируется текущая FAT в следующую страницу памяти. В старой затирается маркер. В новой меняются необходимые данные. Вместо маркеров можно использовать индекс номера текущей страницы с валидной FAT. Безусловно, по скорости такое решение далеко не лучший вариант. Зато несложное в реализации путем доработки исходников той же FatFS от ChaN`а

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

В старой затирается маркер.

А смысл? Все равно ее придется стирать когда дойдет очередь. Может сразу стирать, а маркер текущей страницы сделать отличным от 0xFF?

[kada]

А смысл? Все равно ее придется стирать когда дойдет очередь. Может сразу стирать, а маркер текущей страницы сделать отличным от 0xFF?

Согласен. Упустил наличие необходимости в стирании страницы перед записью.
Маркер, безусловно, должен быть отличным от 0xFF.

А можно вообще ничего не стирать. Пусть маркер имеет значения 0 и 255 (по умолчанию в стертых секторах). Тогда нужный сектор выбираем по "переходу".

Тоже решение. Правда немного усложнится поиск текущего валидного маркера.

Сообщение отредактировал kada - Oct 5 2007, 19:12