|
Хранение файлов на at45db, DataFlash + мк с малыми ресурсами. Как? |
|
|
|
Sep 5 2007, 13:12
|
Участник

Группа: Участник
Сообщений: 44
Регистрация: 30-03-06
Пользователь №: 15 598

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

Группа: Участник
Сообщений: 44
Регистрация: 30-03-06
Пользователь №: 15 598

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

Частый гость
 
Группа: Свой
Сообщений: 106
Регистрация: 23-05-05
Из: Ташкент
Пользователь №: 5 324

|
Цитата(alcosar @ Sep 6 2007, 08:48)  Сам ФАТ нужно хранить в ОЗУ либо мк, либо DataFlash. В мк мало ОЗУ. В DataFlash во время записи используются оба буфера, чтобы ускорить запись. Сам ФАТ во флеши хранится в одной и той же странице. Т.е. запись в нее будет происходить при всякой операции записи. Нет равномерного износа. Может можно сделать по-другому? Исходники уже есть. Выделить несколько страниц для хранения FAT и тем самым создать круговой буфер. В начале FAT предусмотреть некий маркер, по которому можно определить что данная страница содержит в себе валидную FAT. Для чтения из FAT находится страница с маркером. Для записи новой информации в FAT копируется текущая FAT в следующую страницу памяти. В старой затирается маркер. В новой меняются необходимые данные. Вместо маркеров можно использовать индекс номера текущей страницы с валидной FAT. Безусловно, по скорости такое решение далеко не лучший вариант. Зато несложное в реализации путем доработки исходников той же FatFS от ChaN`а
|
|
|
|
|
Sep 6 2007, 11:06
|
Участник

Группа: Участник
Сообщений: 44
Регистрация: 30-03-06
Пользователь №: 15 598

|
Цитата(urasinov @ Sep 6 2007, 07:03)  Может быть вам будет достаточно хранить перед каждым файлом указатель на следующий файл (адрес начала следующего файла) но при большом количестве файлов думаю это будет медленно.
У меня на скорости 115200 успевает писаться с одним буфером, может быть такой скорости для вас будет достаточно. Вариант с указателем достаточно быстрый. На скорости 115200 может прийти 115200/11 = 10470 байт, при 8 битах данных и двух стоповых. Максимальное ремя записи со стиранием в версиях AT45DBxxxD 40 мс. Более ранние версии писали быстрее. За 40 мс может прийти более 440 байт. Если микросхема с размером буфера 256 байт, то нужно приостанавливать передачу или писать во второй буфер в то время когда первый переносится во флеш.
|
|
|
|
|
Sep 7 2007, 04:20
|
Знающий
   
Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153

|
Цитата(Сергей Борщ @ Sep 6 2007, 18:07)  А смысл? Все равно ее придется стирать когда дойдет очередь. Может сразу стирать, а маркер текущей страницы сделать отличным от 0xFF? А можно вообще ничего не стирать. Пусть маркер имеет значения 0 и 255 (по умолчанию в стертых секторах). Тогда нужный сектор выбираем по "переходу". Пример: Код № сектора 1 2 3 4 Маркер 0 255 255 255 Валидный сектор 1.
№ сектора 1 2 3 4 Маркер 0 0 0 0 Валидный сектор 4.
№ сектора 1 2 3 4 Маркер 255 0 0 0 Валидный сектор 1.
№ сектора 1 2 3 4 Маркер 255 255 0 0 Валидный сектор 2.
ну и т.д. Стирать конечно все равно придется, но помоему, лучше, чтобы операция выглядела как: 1. Если надо-стереть 2. Записать а не : 1. Записать 2. Если надо - стереть В первом варианте операция не полагается на то, что тот сектор, в который она начинает писать, был очищен предыдущей операцией
Сообщение отредактировал Непомнящий Евгений - Sep 7 2007, 04:24
|
|
|
|
|
Oct 5 2007, 19:11
|

Частый гость
 
Группа: Свой
Сообщений: 106
Регистрация: 23-05-05
Из: Ташкент
Пользователь №: 5 324

|
Цитата(Сергей Борщ @ Sep 6 2007, 19:07)  А смысл? Все равно ее придется стирать когда дойдет очередь. Может сразу стирать, а маркер текущей страницы сделать отличным от 0xFF? Согласен. Упустил наличие необходимости в стирании страницы перед записью. Маркер, безусловно, должен быть отличным от 0xFF. Цитата(Непомнящий Евгений @ Sep 7 2007, 09:20)  А можно вообще ничего не стирать. Пусть маркер имеет значения 0 и 255 (по умолчанию в стертых секторах). Тогда нужный сектор выбираем по "переходу". Тоже решение. Правда немного усложнится поиск текущего валидного маркера.
Сообщение отредактировал kada - Oct 5 2007, 19:12
|
|
|
|
|
Oct 9 2007, 05:34
|

Местный
  
Группа: Свой
Сообщений: 345
Регистрация: 10-10-05
Пользователь №: 9 459

|
Цитата(Kovrov @ Oct 9 2007, 08:46)  ...и при чтении нет нет да промелькнет где то еденичка.. ... пока не заменил дфлеш. Ну если единичка "промелькнула" то наверняка промелькнет еще раз уже на другой.Тут скорее дело не в мс. Вряд ли заменой мс проблема решилась(просто отложилась на некоторое время). Вопросы ЭМС и т.п. еще никто не отменял  . А полагатся на то что был плохой чип, это самоуспокоение.
--------------------
Если задачу можно решить, то не надо тревожиться. А если нельзя решить, то тревожиться бесполезно.
|
|
|
|
|
Oct 9 2007, 12:24
|
Участник

Группа: Участник
Сообщений: 44
Регистрация: 30-03-06
Пользователь №: 15 598

|
Цитата(Kovrov @ Oct 9 2007, 07:46)  Вот такой вопрос волнует в последнее время.. применяете ли вы, уважаемые колеги, какие нибудь методы контроля за записью или чтением в буфер дата флеш? Вопрос встал достаточно ощутимо после того, как попалась дфлешка с полуживым SPI.. Что значит полуживой? Как проявляется? Цитата и наблюдался такой глюк: читаю полностью страничку памяти 528 байт в ней заранее записаны нули.. Если нельзя без ошибок прочитать, откуда уверенность, что записались нули? С DataFlash работаю давно, еще когда были 5-ти вольтовые. Такого еще не встречал. Правда, есть микросхема у которой не работает запись с буфера в память. На мою удачу это была не первая микросхема с которой я начал изучение DataFlash  .
Сообщение отредактировал alcosar - Oct 9 2007, 12:25
|
|
|
|
|
Oct 10 2007, 05:47
|
Участник

Группа: Участник
Сообщений: 44
Регистрация: 30-03-06
Пользователь №: 15 598

|
Цитата(Kovrov @ Oct 9 2007, 16:15)  Попорядку: как определил полуживость датафлешки.... На самом деле шину параллельно щупал с помощью лог анализатора... по линии MISO наблюдались характерные пики (лог 1) несмотря на то что CS был неактивен (лог 1). далее... статус регистр при обращении не всегда показывал во 2-5 бите "1011" at45db161 мог показывать вообще ересь типа FF или 00 хотя статус читал циклически. И главное: под конец эпопеи данные вообще перестали записываться-считываться.. собственно из за чего и произошла замена и после чего все исчезло, но появились вопросы :-) Что с питанием? Как получаете 3 В?
|
|
|
|
|
Oct 11 2007, 05:33
|
Группа: Новичок
Сообщений: 2
Регистрация: 28-03-07
Пользователь №: 26 571

|
Цитата(kada @ Sep 6 2007, 17:31)  Выделить несколько страниц для хранения FAT и тем самым создать круговой буфер. В начале FAT предусмотреть некий маркер, по которому можно определить что данная страница содержит в себе валидную FAT. Для чтения из FAT находится страница с маркером. Для записи новой информации в FAT копируется текущая FAT в следующую страницу памяти. В старой затирается маркер. В новой меняются необходимые данные. Вместо маркеров можно использовать индекс номера текущей страницы с валидной FAT. Безусловно, по скорости такое решение далеко не лучший вариант. Зато несложное в реализации путем доработки исходников той же FatFS от ChaN`а После реального опыта работы с FatFS без внешнего ОЗУ любые движения по перезаписи нескольких копий FAT видится крайне напряжными. Тем более в случае краха FAT'а крайне сложно будет вытянуть данные имея n+1 несинхронизированных копий FAT. Для реализации же файловых систем, экономно расходующих ресурс циклов перезаписи давно существуют другие решения. Например jffs, jffs2, jffs3 (правда примеров их реализации для Meg'и мне не известно). Кстати, после более-менее осмысленного применения различных файловых систем в своих девайсах интересует горзадо более актуальный вопрос fail safe систем. Есть некотрые мысли, если кому-то интересно можно продолжить обсуждение в этой ветке или создать новую. Цитата(Kovrov @ Oct 9 2007, 11:46)  Вот такой вопрос волнует в последнее время.. применяете ли вы, уважаемые колеги, какие нибудь методы контроля за записью или чтением в буфер дата флеш? Вопрос встал достаточно ощутимо после того, как попалась дфлешка с полуживым SPI.. и наблюдался такой глюк: читаю полностью страничку памяти 528 байт в ней заранее записаны нули.. и при чтении нет нет да промелькнет где то еденичка.. вчера всю голову сломал- думал что это: наводки или косяки в программе. пока не заменил дфлеш. Конечно применям.  Недаром размер страницы 528 байт - есть лишние 16 байт для хранения контрольной суммы или исправляющего кода. Очень актуально не только при битом SPI. Плюс верификация записи. Цитата(alcosar @ Sep 6 2007, 10:48)  Сам ФАТ нужно хранить в ОЗУ либо мк, либо DataFlash. В мк мало ОЗУ. В DataFlash во время записи используются оба буфера, чтобы ускорить запись. ФАТ в ОЗУ хранить может и не получится... он (ФАТ) может быть и достаточно большой  )) Для реально ускорения работы с DF я применял массив из 4 м/с DF с параллельной записью/чтением буфферов (типа страйпинга в райдах). Но на самом деле FAT на Meg'e это больше мучений, чем пользы, ИМХО.
Сообщение отредактировал alsenin - Oct 11 2007, 05:36
|
|
|
|
|
Oct 11 2007, 14:38
|
Участник

Группа: Участник
Сообщений: 44
Регистрация: 30-03-06
Пользователь №: 15 598

|
Цитата(Kovrov @ Oct 10 2007, 19:13)  78L03 Чем запитана 78L03 ? Похоже на проблемы с питанием. Чем пишете/читаете DataFlash ? Atmega? Цитата(alsenin @ Oct 11 2007, 08:33)  Кстати, после более-менее осмысленного применения различных файловых систем в своих девайсах интересует горзадо более актуальный вопрос fail safe систем. Есть некотрые мысли, если кому-то интересно можно продолжить обсуждение в этой ветке или создать новую. Конечно интересно. От FAT я и сам отказался. Интересно как делают другие.
Сообщение отредактировал alcosar - Oct 11 2007, 14:43
|
|
|
|
|
Oct 11 2007, 17:39
|

Мастер-фломастер
   
Группа: Свой
Сообщений: 611
Регистрация: 29-12-05
Пользователь №: 12 700

|
Цитата(alsenin @ Oct 11 2007, 09:33)  Недаром размер страницы 528 байт - есть лишние 16 байт для хранения контрольной суммы или исправляющего кода. Очень актуально не только при битом SPI. Плюс верификация записи. можно обо всем этом поподорбнее. Контрольную сумму можно пропустить...
--------------------
Вон ПОПОВ, клоун клоуном, а радио изобрел!!
|
|
|
|
|
Oct 12 2007, 03:24
|
Группа: Новичок
Сообщений: 2
Регистрация: 28-03-07
Пользователь №: 26 571

|
Цитата(Kovrov @ Oct 12 2007, 00:39)  можно обо всем этом поподорбнее. Контрольную сумму можно пропустить... Если ставить цель - отказоустойчивое хранение информации, то надо исходить из того, что сбой может произойти на любом этапе операции чтения/записи. Поэтому необходимо контролировать не только правильность чтения, но и достоверность записи. Вывод - принимаем решение, что операция записи прошла успешно после верификации записи. Т.е. если по максимуму - сравниваем буфер записи с буфером DF и сравниваем буфер DF со страницей DF. Тоже самое с операцией чтения. В простейшем случае вычисляем и храним контрольную сумму и принимаем решение, что операция чтения завершилась удачно. Либо вычисляем и храним исправляющий код, который позволяет при устойчивых искажениях исправлять одиночные ошибки. Ключевое слово - " Код Хемминга". Для хранения контрольных кодов и выделены дополнительные 16 байт в каждой странице DF, так как все таки это не очень надежный носитель информации. PS. Правда все это не очень применимо для МК с малыми ресурсами  Цитата(alcosar @ Oct 11 2007, 21:38)  Конечно интересно. От FAT я и сам отказался. Интересно как делают другие. Иногда от FAT нельзя отказаться, например если ее использование оговаривается в ТЗ для работы с Windows. Поэтому хочется несколько повысить надежность хранения при использовании FAT. Например введя понятие транзакции в операции записи. Более подробно попробую изложить свои мысли чуть позже, так как жестко не хватает времени.
|
|
|
|
|
Oct 26 2007, 15:08
|

Частый гость
 
Группа: Свой
Сообщений: 106
Регистрация: 23-05-05
Из: Ташкент
Пользователь №: 5 324

|
Цитата(alsenin @ Oct 11 2007, 10:33)  После реального опыта работы с FatFS без внешнего ОЗУ любые движения по перезаписи нескольких копий FAT видится крайне напряжными. Тем более в случае краха FAT'а крайне сложно будет вытянуть данные имея n+1 несинхронизированных копий FAT.
Для реализации же файловых систем, экономно расходующих ресурс циклов перезаписи давно существуют другие решения. Например jffs, jffs2, jffs3 (правда примеров их реализации для Meg'и мне не известно). Это понятно. Но речь идет о AVR-ах, а JFFS ориентирована на более производительные платформы.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|