Приветствую парни!

Вот такой вопрос. У меня плата с процом ПИК24/дсПИК33. Плата должна вести лог файл, новая запись заносится в лог раз в минуту, размер одной записи 150-200 байт. Лог пишется неделю, круглосуточно, по кольцу. Одни сутки - один лог файл, всего получается не более 7ми файлов. Длина имени не имеет значения. Требуется передача лог файлов по ФТП, когда этого захочет удаленный хост. Общий размер памяти требуемый под лог получается грубо, 2 Мегабайта. У меня в принципе всё есть уже, но для работы с СД картой.

Понятно что СД карта - многовато будет для данной задачи, стоимость сд карты+холдер для неё - дороговато, и главное - температурный диапазон. Надо чтоб от -25 хотя бы было. Сразу возникает решение использовать какую нибудь восьми ножковую последовательную флешку, на 64Mbit, к примеру. Но возникает вопрос о файловой системе которая сможет работать с такой памятью. Вот собственно вопрос: был ли у кого опыт с подобными штуками (serial flash + FAT16/32) ?
Может ли FAT16/32 жить на таких флешках вообще?

Саму по себе ФАТ думаю взять у этого товарища http://elm-chan.org/fsw/ff/00index_e.html , добавив низкоуровневые функции доступа к флеши. Та ФАТ что у меня сейчас - это библиотека встроенная в компилятор (МикроСи ПРО для дсПИК), работает исключительно с SD/MMC/CF картами.

Буду благодарен за любую информацию

Файловая система из-за 7-ми записей? Боже, куда катится этот мир!
Что вам мешает сделать простой 2-х мерный массив FILE[7][200]?
Можете хранить его хоть в RAM, хоть в EEPROM...

А при обработке команд от хоста можно имитировать файловую систему.

Я видимо не совсем правильно объяснился. Хотя вроде всё написал:



Одна запись = 200 байт в минуту. В минуту! В часе 60 минут. 60*200*24 = 281Кбайт в сутки. 281*7= ~2 мегабайта весь лог за неделю.





Можно конечно, думал я об этом. Но по сути придется имитировать создание/удаление файлов, открытие/закрытие текущего файла куда писать буду текущую запись... В реале буду рожать своего урода и потом доводить его, вместо того что чтобы взять готовый порт под ПИК и допилить его до доступности к использованию с сериальной флешкой.

Благодарю за ответы

Мда. Теперь понимаю почему переписанный Windows98 уложился в 8кб...
Кто вас заставляет это делать?
"открытие/закрытие файла" - просто когда процессор уходит в спячку (если отключается питание),
записываете индексы последней использованной ячейки памяти.
Когда проснется и придет пора записывать следующую, читаете эти индексы и продолжаете дальше.
"создание/удаление" - увеличиваете на 1 индекс массива, вы же по кругу пишете.
Сила ФАТ, это когда много разных файлов, сильно отличающиеся по объему и по количеству.
Чтоб не терять место в памяти. А у вас и память около 32 раз превышает максимально требуемый объем...
Впрочем, ваше дело решать. Надежность системы обратно пропорциональна ее сложности.

Кроме того, как только Вы сделаете FAT, сразу придется решать проблему частой записи в таблицу занятых кластеров, иначе Вы убьете эти сектора памяти гораздо раньше, чем все остальное.

Есть готовые решения, в свободных исходниках.... На кой хрен мне влазить в тонкости строения файловой системы, чёта имитировать, если её можно просто взять и пользовать ? Допилить готовое почти всегда проще, чем с нуля делать. Надо только правильно оценить ценность того что пилить собираешься. И в данном случае вообще не стоит изобретать велосипед мне кааца. Академически это может быть интересно, но это не тот случай. У меня вполне конкретный вопрос, на который я не услышал еще ответа. Ну не судьба, значит... Всё равно спасибо.



А поподробнее можно?

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

А портировать fatfs на serial flash не предаставляет большой сложности: там будут нужны функции инициализации, статуса, записи и чтения сектора.

Вы имеете ввиду ограничено физически возможностями чипа памяти?

Про портирование - это собственно тот ответ, что я и хотел услышать, чётко и ясно .

Именно так. Сектора перестанут стираться. Мы некоторое время назад пытались найти файловую систему, которая снаружи смотрелась как FAT, а внутри не писала бы в одни и те же сектора - не смогли. Пришлось писать свою. Долго и очень печально. Памяти она оперативной жрет жуткую прорву (мы, правда, под NAND делали, это еще хуже - там сектора большие и еще дополнительные ограничения есть).

Весьма ценный пост, благодарю. Да, не весело прямо скажем. Ладно, значит поставим ОЗУшку. Батарейка (таблетка) на плате всёравно предусмотрена для часиков. Прилеплю супервизор какой-нибудь и буду на случай обрыва питания усыплять проц, а всё остальное, кроме ОЗУ, отключать наглухо.


Удачи!

У майкрочипа есть чудесный аппнот на тему "USB Device - Mass Storage - Internal Flash". Они организуют нормально видимый снаружи диск прямо в флеш-памяти программ микроконтроллера, очень изящно. Это в составе "microchip-application-libraries" пакета, сейчас его архив около 200 МБ.
Это тот самый нижний уровень (организация секторов и доступа к ним). Идея очень красивая, да и реализация неплоха. Я, опираясь на данный аппнот, сделал нужный мне сервис с внешней флэшкой. Уж не скажу сколько от оригинального текста осталось, но началось именно с этого


Я ограничился выделением массива физических секторов для служебной информации, эти сектора пишутся по кругу. Собственно маркера "актуальная копия" нет: я просто стираю следующий сектор, так что если обнаружен пустой сектор в кольце, то значит актуальная копия была в предыдущем.
Увеличил таким образом расчетный ресурс в 1000 раз, посчитал на сколько лет хватит результата и успокоился.
Ну и, конечно, кэширование в RAM в процессе работы, то есть не каждый "чих" сиюмгновенно в флэш попадает.
(это я в PIC18 делал, на более старших моделях код гораздо веселее реализуется, но логика не меняется)


Несколько нерационально, если Вы хотите то, о чем спрашивали вначале (известная до начала проектирования структура "диска"). Достаточно хранить данные как Вам удобно, а запросы на доступ извне (посекторный доступ, в том числе и доступ к служебным секторам FAT) обрабатывать специальным образом.

Как-то все упустили вводные из первого поста: данные выкачиваются через FTP, соответственно, никакого "посекторного доступа" и не требуется.

Имеем FAT12 :
1. 0 сектор - MBR
2. 1-18 сектора - сам фат и его копия ( по 9 секторов )
3. 19-32 сектора - корневая директория (14 секторов по 16 директорий)

Я так понимаю при записи в файл будут меняться сектора с 1-18, при создании или удалении файлов - 19-32 сектора или ,если файл только 1, будет стираться только 19 сектор ?

Это уж как операционке заблагорассудится.

1. Откуда столько секторов на FAT12 ? при 8 мегабайт и кластере 32К (64 сектора) имеем меньше сектора на FAT. То есть 1 сектор используется.
2. Укажите явно, что у Вас 1 кoпия FAT (BPB_NumFATs = 1)
3. Укажите явно, что у Вас может быть только 16 записей в корневой директории (BPB_RootEntCnt = 16). Тогда длина корневой директории будет 1 сектор.

Итого 2 сектора-то и нужно.

Я подобным путем развлекался с "диском" 4 мегабайта. никаких проблем пока не замечено.


Неправильно. При каждом изменении в файле могут измениться как FAT( добавится/удалится новый сектор в цепочке), так и RootDir (меняется длина файла и время).
Более того- что операционка сделает при изменении файла- это ее личное дело. Захочет- просто байтики добавит-удалит на диск, захочет- вообще запишет новую копию файла в другие сектора а эти освободит. ее право.


P.S. Если Вы еще не ознакомились, то настоятельно рекомендую для прочтения файл
http://staff.washington.edu/dittrich/misc/fatgen103.pdf

Еще есть его русскоязычный перевод.
http://usuperl.googlecode.com/svn-history/...tgen103-rus.pdf

Это, так сказать, "золотой фонд"
Без "вкуривания" оного не советую в эту тему лезть.

Upd: Извиняюсь, но это не Вы писали про 64 мегабита? и про только несколько файлов на диске? тогда про 1 сектор на FAT и про нужную длину RootDir посчитать нужно, может у Вас и не ограничиться двумя секторами под служебку.

FAT не самая удачная система под вашу задачу ибо она хранит таблицу кластеров.

Поэтому рекомендую найти-написать систему попроще ибо.
1. Размер файла фиксирован
2. Чисто файлов фиксировано
3. Запись идёт по кругу

Ставь MRAM (максимально что есть эт 4MB MR25H40) от Everspin Technologies http://www.everspin.com/products.php?hjk=SERIAL&a1f3=4Mb есть и 2MB как раз твой размер, ну или FRAM, смотря какая религия.
Файловая система будет вносить задержки, скажем если лог с временем или может пропустить следующее событие которое нужно записать в лог.
Тупой табличной записью было бы по разумнее, имхо фат нужна когда есть неопределенные во время разработки количество и размер файлов. Ну или когда заказчик любит менять все по ходу дела.
Удачи в бою