78L03

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

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

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





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

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




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

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

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

Сообщение отредактировал alsenin - Oct 11 2007, 05:36

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


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

Сообщение отредактировал alcosar - Oct 11 2007, 14:43

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

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

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

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

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




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

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

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

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

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