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

А собсно чем не нравится FatFS от ChaN`а?
Я так просмотрел ваш текстовичёк - прийдётся вам конечно поработаь над его исходниками, но в принципе это не смертельно...

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

Может быть вам будет достаточно хранить перед каждым файлом указатель на следующий файл (адрес начала следующего файла) но при большом количестве файлов думаю это будет медленно.

У меня на скорости 115200 успевает писаться с одним буфером, может быть такой скорости для вас будет достаточно.

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

Вариант с указателем достаточно быстрый.
На скорости 115200 может прийти 115200/11 = 10470 байт, при 8 битах данных и двух стоповых.
Максимальное ремя записи со стиранием в версиях AT45DBxxxD 40 мс. Более ранние версии писали быстрее. За 40 мс может прийти более 440 байт. Если микросхема с размером буфера 256 байт, то нужно приостанавливать передачу или писать во второй буфер в то время когда первый переносится во флеш.

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

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

Стирать конечно все равно придется, но помоему, лучше, чтобы операция выглядела как:
1. Если надо-стереть
2. Записать
а не :
1. Записать
2. Если надо - стереть
В первом варианте операция не полагается на то, что тот сектор, в который она начинает писать, был очищен предыдущей операцией

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


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

Вот такой вопрос волнует в последнее время..
применяете ли вы, уважаемые колеги, какие нибудь методы контроля за записью или чтением в буфер
дата флеш?
Вопрос встал достаточно ощутимо после того, как попалась дфлешка с полуживым SPI..
и наблюдался такой глюк:
читаю полностью страничку памяти 528 байт
в ней заранее записаны нули..
и при чтении нет нет да промелькнет где то еденичка..
вчера всю голову сломал- думал что это: наводки или косяки в программе.
пока не заменил дфлеш.

Ну если единичка "промелькнула" то наверняка промелькнет еще раз уже на другой.Тут скорее дело не в мс. Вряд ли заменой мс проблема решилась(просто отложилась на некоторое время). Вопросы ЭМС и т.п. еще никто не отменял . А полагатся на то что был плохой чип, это самоуспокоение.

Возможно не спорю...
ну и тем не менее вопрос остается открытым.

Что значит полуживой? Как проявляется?

Если нельзя без ошибок прочитать, откуда уверенность, что записались нули?
С DataFlash работаю давно, еще когда были 5-ти вольтовые. Такого еще не встречал. Правда, есть микросхема у которой не работает запись с буфера в память. На мою удачу это была не первая микросхема с которой я начал изучение DataFlash .

Попорядку:
как определил полуживость датафлешки....
На самом деле шину параллельно щупал с помощью лог анализатора...
по линии MISO наблюдались характерные пики (лог 1) несмотря на то что CS был неактивен (лог 1).
далее... статус регистр при обращении не всегда показывал во 2-5 бите "1011" at45db161
мог показывать вообще ересь типа FF или 00 хотя статус читал циклически.
И главное: под конец эпопеи данные вообще перестали записываться-считываться..
собственно из за чего и произошла замена и после чего все исчезло, но появились вопросы :-)

Что с питанием? Как получаете 3 В?

78L03

После реального опыта работы с FatFS без внешнего ОЗУ любые движения по перезаписи нескольких копий FAT видится крайне напряжными. Тем более в случае краха FAT'а крайне сложно будет вытянуть данные имея n+1 несинхронизированных копий FAT.

Для реализации же файловых систем, экономно расходующих ресурс циклов перезаписи давно существуют другие решения. Например jffs, jffs2, jffs3 (правда примеров их реализации для Meg'и мне не известно).

Кстати, после более-менее осмысленного применения различных файловых систем в своих девайсах интересует горзадо более актуальный вопрос fail safe систем. Есть некотрые мысли, если кому-то интересно можно продолжить обсуждение в этой ветке или создать новую.





Конечно применям.

Недаром размер страницы 528 байт - есть лишние 16 байт для хранения контрольной суммы или исправляющего кода. Очень актуально не только при битом SPI. Плюс верификация записи.




ФАТ в ОЗУ хранить может и не получится... он (ФАТ) может быть и достаточно большой ))

Для реально ускорения работы с DF я применял массив из 4 м/с DF с параллельной записью/чтением буфферов (типа страйпинга в райдах).

Но на самом деле FAT на Meg'e это больше мучений, чем пользы, ИМХО.

Чем запитана 78L03 ? Похоже на проблемы с питанием. Чем пишете/читаете DataFlash ? Atmega?


Конечно интересно. От FAT я и сам отказался. Интересно как делают другие.

можно обо всем этом поподорбнее.
Контрольную сумму можно пропустить...

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

Тоже самое с операцией чтения. В простейшем случае вычисляем и храним контрольную сумму и принимаем решение, что операция чтения завершилась удачно. Либо вычисляем и храним исправляющий код, который позволяет при устойчивых искажениях исправлять одиночные ошибки. Ключевое слово - "
Код Хемминга".

Для хранения контрольных кодов и выделены дополнительные 16 байт в каждой странице DF, так как все таки это не очень надежный носитель информации.

PS. Правда все это не очень применимо для МК с малыми ресурсами




Иногда от FAT нельзя отказаться, например если ее использование оговаривается в ТЗ для работы с Windows. Поэтому хочется несколько повысить надежность хранения при использовании FAT.

Например введя понятие транзакции в операции записи.

Более подробно попробую изложить свои мысли чуть позже, так как жестко не хватает времени.

понятно. спасибо.
А что вы считаете более подходящим для хранения информации?

Это понятно. Но речь идет о AVR-ах, а JFFS ориентирована на более производительные платформы.