[Berkl 0]

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

 

Вот такой вопрос. У меня плата с процом ПИК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 картами.

 

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

 

 

[evc 0]

Файловая система из-за 7-ми записей? Боже, куда катится этот мир!

Что вам мешает сделать простой 2-х мерный массив FILE[7][200]?

Можете хранить его хоть в RAM, хоть в EEPROM...

[mp41 0]

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

[Berkl 0]

Файловая система из-за 7-ми записей? Боже, куда катится этот мир!

Что вам мешает сделать простой 2-х мерный массив FILE[7][200]?

Можете хранить его хоть в RAM, хоть в EEPROM...

 

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

 

Плата должна вести лог файл, новая запись заносится в лог раз в минуту, размер одной записи 150-200 байт. Лог пишется неделю, круглосуточно, по кольцу.

 

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

 

 

 

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

 

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

 

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

 

 

[evc 0]

...Но по сути придется имитировать создание/удаление файлов, открытие/закрытие текущего файла куда писать буду текущую запись...

 

Мда. Теперь понимаю почему переписанный Windows98 уложился в 8кб...

Кто вас заставляет это делать?

"открытие/закрытие файла" - просто когда процессор уходит в спячку (если отключается питание),

записываете индексы последней использованной ячейки памяти.

Когда проснется и придет пора записывать следующую, читаете эти индексы и продолжаете дальше.

"создание/удаление" - увеличиваете на 1 индекс массива, вы же по кругу пишете.

Сила ФАТ, это когда много разных файлов, сильно отличающиеся по объему и по количеству.

Чтоб не терять место в памяти. А у вас и память около 32 раз превышает максимально требуемый объем...

Впрочем, ваше дело решать. Надежность системы обратно пропорциональна ее сложности.

[Alex11 3]

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

[Berkl 0]

Мда. Теперь понимаю почему переписанный Windows98 уложился в 8кб...

Кто вас заставляет это делать?

"открытие/закрытие файла" - просто когда процессор уходит в спячку (если отключается питание),

записываете индексы последней использованной ячейки памяти.

Когда проснется и придет пора записывать следующую, читаете эти индексы и продолжаете дальше.

"создание/удаление" - увеличиваете на 1 индекс массива, вы же по кругу пишете.

Сила ФАТ, это когда много разных файлов, сильно отличающиеся по объему и по количеству.

Чтоб не терять место в памяти. А у вас и память около 32 раз превышает максимально требуемый объем...

Впрочем, ваше дело решать. Надежность системы обратно пропорциональна ее сложности.

 

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

 

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

 

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

Изменено 14 декабря, 2012 пользователем berkl

[Croman13n3c 0]

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

 

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

[Berkl 0]

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

 

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

 

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

 

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

 

[Alex11 3]

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

[Berkl 0]

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

 

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

 

 

Удачи!

 

[Ruslan1 16]

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

Это тот самый нижний уровень (организация секторов и доступа к ним). Идея очень красивая, да и реализация неплоха. Я, опираясь на данный аппнот, сделал нужный мне сервис с внешней флэшкой. Уж не скажу сколько от оригинального текста осталось, но началось именно с этого :)

 

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

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

Увеличил таким образом расчетный ресурс в 1000 раз, посчитал на сколько лет хватит результата и успокоился.

Ну и, конечно, кэширование в RAM в процессе работы, то есть не каждый "чих" сиюмгновенно в флэш попадает.

(это я в PIC18 делал, на более старших моделях код гораздо веселее реализуется, но логика не меняется)

 

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

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

[aaarrr 63]

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

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

[Croman13n3c 0]

Имеем FAT12 :

1. 0 сектор - MBR

2. 1-18 сектора - сам фат и его копия ( по 9 секторов )

3. 19-32 сектора - корневая директория (14 секторов по 16 директорий)

 

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

 

[Alex11 3]

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