Кто еще хорошо помнит как устроен FAT? Опции

[Allregia]

Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький.
Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы?
Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

Правда, если файл сначала удалят, а потом на его место запишут другой, то тогда он уже не попадет на те-же сектора?
А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был?

[AlexRayne]

Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький.
Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы?
Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

Правда, если файл сначала удалят, а потом на его место запишут другой, то тогда он уже не попадет на те-же сектора?

атрибут систем не гарантирует ничего - это некий атрибут "прав доступа" чтоли - что с фалом можно делать а что нельзя.он работает исключаительно как информация, и все АПИ работы с файлами атрибутов не учитывают. атрибуты даются пользователю исключительно. ну может быть вы встретите библиотеку которая их учитывает, но я такого не видел.

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

А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был?

Да это сработает.

Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

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

[adnega]

Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

Проще отказаться от такого сомнительного требования и сделать все правильно.
Мучить одни и те же сектора не для всех носителей хорошая идея.

[CrimsonPig]

Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький.
Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы?
Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

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

[megajohn]

А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был?

Выскажу глупое предложение, проверить вживую на FatFS

[HardEgor]

А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был?

Проще наверное сделать раздел размером с этот файл.

[jcxz]

Проще наверное сделать раздел размером с этот файл.

Проще тогда не использовать ФС.

Выскажу глупое предложение, проверить вживую на FatFS

Выскажу неглупое предположение, что раз так поставлена задача - обойти ФС, то очевидно она вообще не нужна.

[Guest_TSerg_*]

Делается контейнер, по примеру TrueCrypt и размером с файл и в нем файл будет в безопасности по местоположению.

[Allregia]

Да это сработает.

Ну, по видимому этого будет достаточно.

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

У меня нет библиотеки ФАТ, с ней не я работаю а извне.

Проще отказаться от такого сомнительного требования и сделать все правильно.
Мучить одни и те же сектора не для всех носителей хорошая идея.

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

Никто ничего не гарантирует. Все зависит от того, как конкретная имплементация файловой системы обращается с секторами,

В 99/999% случаев - это будет Винда.

Проще наверное сделать раздел размером с этот файл

Именно так и было сделано, пока файл был один.
Вопросы возникли, когда понадобилось кроме одного большого файла, иметь еще маленький, размером в несколько секторов/кластеров (в данном случае он у меня совпадают, по 512 байт).
Эти два файла занимают все место на диске, точнее - диск выглядит размером с суммарный размер обоих файлов.

Проще тогда не использовать ФС.

Осталось только обяснить это компу

Я не описывал подробностей, т.к. недумал что это имеет значение к вопросам исключительно по FAT, но видимо придется - файлы расположены на USB MSD девайсе, подключаемому к компу, поэтому всей работой с файловой системой занимается винда (ну может один из тысячи и будет использовать что-то другое), а девай только предоставляет различные области памяти для Boot, RootDirectory, FAT12. и собственно, содержимому файлов.
Для одного большого файла оно давно и успешно применяется.

[Ruslan1]

Я не описывал подробностей, т.к. недумал что это имеет значение к вопросам исключительно по FAT, но видимо придется - файлы расположены на USB MSD девайсе, подключаемому к компу, поэтому всей работой с файловой системой занимается винда (ну может один из тысячи и будет использовать что-то другое), а девай только предоставляет различные области памяти для Boot, RootDirectory, FAT12. и собственно, содержимому файлов.

Я не понял, почему нельзя сделать в данном случае просто полную совместимость снаружи с FAT, зачем какие-то ограничения?
просто перекодируете внешние запросы фата к секторам в запросы к памяти и все. Задача классическая и решение много где описано- эмуляция фата на флеше.
У майкрочипа есть отличный аппноут, ищите по "Microchip Memory Disk Drive File System", я когда-то его как основу использовал для похожей задачи: кусок памяти прикидывался маленькой юсб флешкой с FAT12. Доступ к Boot и Root у меня вообще в микроконтроллер обрабатывал (реально таких секторов не хранил, память экономил), а остальное- в изменяемой флешке.

Обязательно нужно полностью поддерживать фат без всяких ограничений "что, куда, как и сколько писать" - эти ограничения будут жить до первого юзера и прибор придет в ремонт. Или же это случится из-за запуска формата-чекдиска-посекторного редактора- любая из этих софтин должна нормально работать с Вашей "флешкой".
Или вообще не используйте FAT, или делайте все правильно.

[Allregia]

или делайте все правильно.

"Правильно" - это как?

Я не понял, почему нельзя сделать в данном случае просто полную совместимость снаружи с FAT, зачем какие-то ограничения?

Так и сделано - снаружи полная соввметимость.

просто перекодируете внешние запросы фата к секторам в запросы к памяти и все.

Это и сделано - ФАТ ссылается на сектора в памяти. Но мне нужно, чтобы File_A и File_B всегда в памяти размещались по конкретным адресам.
Микрочиповскую аппноту я знаю, но не очень понял причем тут она - в ней как использовать память как диск, это совсем другое и у них там нет задачи размещать файлы по конкретным адресам в памяти.

[adnega]

Но мне нужно, чтобы File_A и File_B всегда в памяти размещались по конкретным адресам.

Зачем? Вам же говорят забейте на сектора! Вы знаете таблицу FAT и при обращении к сектору вы можете понять смещение в файле.
Зная смещение, выдавайте порцию данных, которая этому смещению соответствует. Данные вообще могут быть не в секторах, а генерироваться на лету.
Компу с Виндой тоже будет легче, т.к. запись в файл стандартными средствами позволит вам задавать только смещение в файле
без необходимости указывать физические сектора.

Кста: вы же таблицу FAT можете генерить на лету, а не где-то хранить. Можно при каждом новом подключении генерить эту таблицу так, чтобы фрагментации не было вообще.

[Allregia]

Зачем? Вам же говорят забейте на сектора! Вы знаете таблицу FAT и при обращении к сектору вы можете понять смещение в файле.

Именно так и делается.

Зная смещение, выдавайте порцию данных, которая этому смещению соответствует. Данные вообще могут быть не в секторах, а генерироваться на лету.
Компу с Виндой тоже будет легче, т.к. запись в файл стандартными средствами позволит вам задавать только смещение в файле
без необходимости указывать физические сектора.
Кста: вы же таблицу FAT можете генерить на лету, а не где-то хранить. Можно при каждом новом подключении генерить эту таблицу так, чтобы фрагментации не было вообще.

Таблица ФАТ и RootDir и генерируются каждый раз при включении, конечно без фрагментации.
В общем, проблема может быть только если сначала удалили оба файла, а потом записали первый маленький и затем большой - тогда маленьккий попадет в начало а большой за ним, изначально оно наоборот.
Но ничего страшного не случится - надо будет просто переподключить устройство к компу и записать заново, уже в правильном порядке, или не удалять файлы а просто перезаписывать (т.е. копировать туда новый файл но с тем-же именем).

[adnega]

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

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

[jcxz]

Но ничего страшного не случится - надо будет просто переподключить устройство к компу и записать заново, уже в правильном порядке, или не удалять файлы а просто перезаписывать (т.е. копировать туда новый файл но с тем-же именем).

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

Если на стороне винды пишет Ваше ПО, то в винде насколько помню есть функции позволяющие сделать некешируемую запись на диск (или сбросить кеш записи). Но опять-же - никто не гарантирует как драйвер ФС винды преобразует смещения в файле в кластера FAT.

[HardEgor]

Именно так и было сделано, пока файл был один.
Вопросы возникли, когда понадобилось кроме одного большого файла, иметь еще маленький, размером в несколько секторов/кластеров (в данном случае он у меня совпадают, по 512 байт).
Эти два файла занимают все место на диске, точнее - диск выглядит размером с суммарный размер обоих файлов.

Ok. Сделайте два раздела - один большой и один маленький.

[Allregia]

Ok. Сделайте два раздела - один большой и один маленький.

Думал об этом, но честно говоря - немного запутался с MBR и прочим, и пока оставил как есть. Может еще вернусь.

[sigmaN]

Я не понял, т.е. все эти танцы с бубном нужны исключительно ради того, чтобы не делать нормальную поддержку FAT в самом девайсе?
Эти костыли вас не смущают?

[YAM]

В таких случаях я делаю просто 2 диска с необходимыми размерами. Тем более что это очень просто и нет чехарды потом что какому файлу принадлежит...

[Allregia]

Я не понял, т.е. все эти танцы с бубном нужны исключительно ради того, чтобы не делать нормальную поддержку FAT в самом девайсе?
Эти костыли вас не смущают?

Видимо да, Вы не поняли. А какие именно"костыли" и в чем Вы видите "полную поддержку ФАТ в самом девайсе"?

В таких случаях я делаю просто 2 диска с необходимыми размерами. Тем более что это очень просто и нет чехарды потом что какому файлу принадлежит...

Я уже писал выше - не разобрался до конца с MBR, чтобы сделать два диска, ну а потом "попустило" - проблема в основном надуманная, просто нудна определенная последовательность действий. При этом не правильная последовательность ни к чему катастрофческому не приводит, все сразу восстанавливается.

[YAM]

Я уже писал выше - не разобрался до конца с MBR, чтобы сделать два диска....

При чем тут MBR к двум дискам?
Не 2 раздела на одном диске, а 2 диска.

[Allregia]

При чем тут MBR к двум дискам?
Не 2 раздела на одном диске, а 2 диска.

Это через LUN?

[sigmaN]

Видимо да, Вы не поняли. А какие именно"костыли" и в чем Вы видите "полную поддержку ФАТ в самом девайсе"?

"Правильно" - это как?

Так и сделано - снаружи полная соввметимость.

Это и сделано - ФАТ ссылается на сектора в памяти. Но мне нужно, чтобы File_A и File_B всегда в памяти размещались по конкретным адресам.
Микрочиповскую аппноту я знаю, но не очень понял причем тут она - в ней как использовать память как диск, это совсем другое и у них там нет задачи размещать файлы по конкретным адресам в памяти.

Имелась ввиду на столько полная поддержка FAT в девайсе, что при необходимости работы с данными файлов File_A и File_B девайс учитывает таблицу FAT и таким образом отпадет требование непременно размещать эти файлы по конкретным адресам в памяти. Но в принципе перечитал ветку, это уже обсудили. Раз точно есть требование размещать файлы по конкретным адресам и оно незыблемо то и возникают желания FAT "обмануть" и заставить делать то, что вы хотите. На сколько я понимаю, это немного "противоестественно" для файловой системы, потому я осмелился назвать это костылями.
В целом такое "противоестественное" использование ФС наводит на мысли, что вы решаете какую-то более высокоуровневую задачу не совсем правильными способами... Впрочем это уже тоже отмечалось ранее другими участниками обсуждения.

[Allregia]

Имелась ввиду на столько полная поддержка FAT в девайсе, что при необходимости работы с данными файлов File_A и File_B девайс учитывает таблицу FAT и таким образом отпадет требование непременно размещать эти файлы по конкретным адресам в памяти.

Девайс сам по себе, когда он не подключен к USB вообще не работает с этими файлами, да и когда подключен - тоже. С ними работает подключенный комп.

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

Да никакая это не "свысокоуровневая задача", как раз наоборот, весьма "низкого уровня", написана без всяких SPL/HAL, чтобы поменьше места занимала, пока в 6 килобайт вместился - она запускается при подключении устройства к РС, и ничего не далает, кроме как позволяет с РС переписать два файла. Т.е сама программа не работает с файловой системой, она только предоставляет ее для доступа с РС.

[CrimsonPig]

Да никакая это не "свысокоуровневая задача", как раз наоборот, весьма "низкого уровня", написана без всяких SPL/HAL, чтобы поменьше места занимала, пока в 6 килобайт вместился - она запускается при подключении устройства к РС, и ничего не далает, кроме как позволяет с РС переписать два файла. Т.е сама программа не работает с файловой системой, она только предоставляет ее для доступа с РС.

Ну так и запретите в своем девайсе запись в сектор, где хранятся directory entries ваших "файлов" и в FAT вообще. Ни стереть, ни удалить ничего будет нельзя, а писать внутрь уже существующих файлов - можно.
Или сейчас опять откроется пачка секретных требований, которые некто утаил в силу своей хитрости ?

[Allregia]

Ну так и запретите в своем девайсе запись в сектор, где хранятся directory entries ваших "файлов" и в FAT вообще. Ни стереть, ни удалить ничего будет нельзя, а писать внутрь уже существующих файлов - можно.

Хорошая мысль! Завтра попробую!

[controller_m30]

Я недавно делал USB MSD с программной генерацией: MBR, BS, FAT, Root, и тремя файлами в корневом каталоге. Два файла фиксированной длины, и один переменной, который иногда должен переписываться. Вся "флешка" объёмом около 1мб. Файловая система FAT16.
Вроде бы здесь о похожем говорят В общем приведу по памяти, вдруг то что надо.

При перезаписи переменного файла (например он назывался File.exe) Винда делает так.

1. В корневой каталог записывается новый блок данных, в котором у File.exe поля: длина и начальный кластер - равны 0.
2. В FAT1 записываются новые данные, где вся цепочка кластеров этого файла равна 0.
3. Аналогично дублируется FAT2.
4. В корневом каталоге у файла File.exe прописываются стартовый адрес кластера и новая длина в байтах (т.е. Root снова переписывается).
У меня стартовый кластер равен тому-же, что был и у предыдущей версии файла.
5. FAT1 записывается новая таблица, где очищенные до этого кластеры заполнены новой цепочкой.
6. FAT2 дублируется.
7. В корневом каталоге у файла File.exe меняются поля "Дата последн. записи" и "Время последн. записи" на новые (т.е. Root ещё раз переписывается).
8. Записывается тело файла в те-же сектора где была прежняя версия.
9. В корневом каталоге снова делается запись с изменённым полем времени (снова запись Root).
10. Делается ещё одна запись с изменённым полем времени (и ещё раз пишется Root).

По пунктам 7,9,10 я сейчас точно не помню, какие временные поля, и в какой очерёдности переписываются. Помню только что их три: дата создания, дата модификации, и дата открытия. И вроде бы, оно три раза те поля и переписывает. Почему это делается в три приёма (а не за один раз) я не помню. Вроде бы поле "дата модификации" несколько раз переписывается... зачем-то... Не помню
Чтения секторов при этом процессе вообще нет. Как считала Винда всё в кэш при подключении, так из кэша все сведения и черпает: и FAT1,2 и Root.

[sigmaN]

Да никакая это не "свысокоуровневая задача", как раз наоборот, весьма "низкого уровня", написана без всяких SPL/HAL, чтобы поменьше места занимала, пока в 6 килобайт вместился - она запускается при подключении устройства к РС, и ничего не далает, кроме как позволяет с РС переписать два файла. Т.е сама программа не работает с файловой системой, она только предоставляет ее для доступа с РС.

Ну послушайте, раз эти файлы с компа могут переписываться до для чего-то это нужно! Следовательно дальше ваш девайс эти файлы таки использует каким-то образом! Это очеивдно!
Так вот вы сейчас используете некий ХАК. Вы всё подстроили таким образом, чтобы для определенного файла была использована известная область памяти, далее прошивка ожидает данные файла в этой области памяти. Таким образом вы всё-же читаете файл, но в обход файловой системы! Я бы не назвал это хорошим дизайном и я думаю многие из присутствующих здесь согласятся.

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

Ну так и запретите в своем девайсе запись в сектор, где хранятся directory entries ваших "файлов" и в FAT вообще

Залочить полностью не получится, там же как минимум венда захочет время модифицировать при перезаписи. Выше вам уже написали об этом и не только.
Опять же это какие-то странные попытки изнасиловать FAT! Венда однозначно пожалуется что таблица FAT не может быть модифицирована и предложит проверить диск....

Мой вам совет, сядьте, потратьте некоторое кол-во времени и килобайтов и читайте в своей прошивке файлы как файлы!
Т.е. в итоге у вас будет выделен некий бОльший кусок памяти достаточный для хранения FAT1+FAT2 + file_a + File_b и именно этот кусок памяти целиком вы будете показывать наружу через USB - это будет как-бы отформатированный в FAT диск. А также сами при необходимости получить данные файлов будете обращаться к этому диску как к файловой системе, через свой драйвер FAT и читать файлы как файлы. Тогда вам будет всё равно по каким они адресам размещены и в каком порядке венда пишет кластеры.
Мне кажется это будет единственный способ сделать это без костылей.

[Ruslan1]

Allregia, извините, пожалуйста, но я просто не могу понять где же проблема. Наверное, старость....

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

Да, конечно, при обращении к сектору нужно на основе ФАТа понять что это такое- какой файл и какая часть файла запрошены и обратиться к соответствующей области физической памяти.
Считается очень просто. У меня простенький PIC18 на 1 мегасемпле справлялся с задачей прикинуться USB флешкой, а Вы в теме "ARM 32 бит" вопрос разместили, так что с ресурсами точно вопросов не должно быть.

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


Но опять же не понимаю даже зачем требование к предопределенности адресов в памяти- просто при записи данных действуйте согласно ФАТу. То есть достаточно иметь таблицу перекодировки "сектор псевдодиска - адрес в памяти", и через эту таблицу и читать и писать.

[sigmaN]

Но опять же не понимаю даже зачем требование к предопределенности адресов в памяти- просто при записи данных действуйте согласно ФАТу. То есть достаточно иметь таблицу перекодировки "сектор псевдодиска - адрес в памяти", и через эту таблицу и читать и писать.

Этот способ однозначно умнее прибивания адресов гвоздями, как того желает автор. Но все равно так и хочется сказать в ответ на это: "что только люди не придумают, лишь бы не подтягивать в проект FatFs"

Может ТС не знает, но http://elm-chan.org/fsw/ff/00index_e.html

[gerber]

Если хотите внутри устройства сами управлять расположением файлов, то вам надо использовать не Mass Storage, а Media Transfer Protocol. В отличие от Mass Storage, работающего на уровне секторов диска, MTP работает на уровне файлов, и атомарной операцией является не запись/чтение сектора, а запись/чтение файла.
Кроме того, MTP имеет ряд интересных плюшек, типа умения уведомлять компьютер об изменениях в файловой системе или содержании файлов, чтобы операционная система перечитала файлы или каталоги с устройства.

[Allregia]

недавно делал USB MSD с программной генерацией: MBR, BS, FAT, Root, и тремя файлами в корневом каталоге. Два файла фиксированной длины, и один переменной, который иногда должен переписываться. Вся "флешка" объёмом около 1мб. Файловая система FAT16.
Вроде бы здесь о похожем говорят

Похоже, только у меня FAT12, второй копии ФАТ нет, и обьем намного меньше.
Boot, Root прописаны как const (не полностью конечно), FAT - генерируется. Это чтобы умньшить обьем занимаемой памяти во флешке проца.

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

А идея с не записью не только в Boot, но и FAF и Root не прошла, имнно из-за кеширования.
Но это не важно, цель достигнута - неправильные действия не приводят к фатальным последствиям и погут быть исправлены повторением правильными.
"Неправидьные действия" - это удаление файлов, их нужно просто перезаписывать с тем-же именем.
Если же файлы удалены, то вначале надо (тут уже можно и с другим именем) писать болшой, потом маленький (именно в таком порядке они расположены в памяти).

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

Этого не нужен - в этом режиме, само устройство не изменяет файлы.
Если кто еще не догадался, это бутлоадер
Развитие идеи AN-10866 от NXP.
У них было в одним файлом на весь "диск", это работает у меня на несколькиз разных процах (и LPC и STM32), но тут я кроме фирмваре (большой файл), добавил еще блок параметров (маленький файл), который можно менять независимо от фирмваре (или вместе).

Может ТС не знает, но http://elm-chan.org/fsw/ff/00index_e.html

ТС конечно знает FatFs и применял ее много раз
В данном случае, в устройстве ее нет - FatFs нужна к обращению к файловой системе ИЗ устройства, а тут устройство не обращается к файловой системе, к ней обращается только Винда, а устройство предоставляет свою память как диск.
В основном режиме работы это вообще все не работает, т.к. это бутлоадер, а та память что была "диском" в бутлоадере - это основная прошивка и блок параметерв/настроек.

[Kabdim]

Не проще, добавлять параметры суфиксом к прошивке и заливать 1 файлом? Вряд ли же эта схема аля пользователь с шестнадцатеричным редактором наперевес похачил параметры и залил их обратно?

[Allregia]

Не проще, добавлять параметры суфиксом к прошивке и заливать 1 файлом?

Так раньше и было, просто сейчас решил сделать поудобнее.

Не проще, добавлять параметры суфиксом к прошивке и заливать 1 файлом? Вряд ли же эта схема аля пользователь с шестнадцатеричным редактором наперевес похачил параметры и залил их обратно?

Можно конечно и с НЕХ-редактром, (их я думаю нынче полно всяких, я как пользовался 20-25 лет назад HIEW, так им и пользуюсь, когда надо), но вообще для формирования файл с настройками есть специальная программка на РС.

[sigmaN]

Media Transfer Protocol в этом случае выглядит очень привлекательно. На много красивее чем предложенный мной FatFS внутри девайса. Особенно учитывая что это бут.

P.S.
Хотя ндааа, учитывая некоторые особенности этого MTP.... https://ru.wikipedia.org/wiki/Media_Transfer_Protocol сомнительная тоже штуковина..

[Kabdim]

Так раньше и было, просто сейчас решил сделать поудобнее. Можно конечно и с НЕХ-редактром, (их я думаю нынче полно всяких, я как пользовался 20-25 лет назад HIEW, так им и пользуюсь, когда надо), но вообще для формирования файл с настройками есть специальная программка на РС.

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

[Allregia]

На много красивее чем предложенный мной FatFS внутри девайса.

FatFs внутри девайса, в данном случае, как телеге пятое колесо - для доступа процессора к памяти он не нужен, а извне все его функции делает Винда.

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

Меньше ошибок.
В предыдушей схеме, редактор настроек при формировании файла, брал файл фирмваре и добавлял к нему блок настроек, потом сохранял это в едином файле для загрузки.
Были случаи, когда юзер брал устаревший файл фирмваре, поэтому и решили сделать их независимыми.
Плюс, для просто обновления прошивки, не нужно вообще никакого софта, я это делаю FAR'ом, а вообще - любым файловым менеджером, хоть виндовым проводником.

(файл фирмваре, естественно зашифрованный).

А проблему смены формата блока настроек в новых прошивках (если таковая произошла), мы решаем сменой сигнатуры - новые настройки просто не воспримутся и будут восстановлены дефолтные с предупреждением.

[Kabdim]

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

[CrimsonPig]

FatFs внутри девайса, в данном случае, как телеге пятое колесо - для доступа процессора к памяти он не нужен, а извне все его функции делает Винда.

Ну, на самом деле, если не нужны функции записи данных в файловой системе, то остаток (только чтение файлов) это всего лишь 10% от функциональности\размера кода.
Если еще жестко завязаться на тип, к примеру FAT12, и отсутствие директорий (кроме root), то разбор этого несчастного фата и чтение данных из cluster chain
займет строк 500 кода с обширными комментариями.

Да, кстати... если ваше устройство прикидывается mass storage и эмулирует FAT FS на лету, может вам на лету и эмулировать root directory вместе с dir. entry ваших хитрых файлов ?

[controller_m30]

По поводу защиты от удаления, но не перезаписи.
Удаление начинается с записи числа 0хЕ5 в первый символ названия файла. По этому признаку можно отличить, что пользователь замыслил именно удаление а не перезапись. И такую транзакцию можно просто заблокировать до её завершения. ПО контроллера исправно примет все данные от компа, отрапортует о больших успехах - но физической записи не сделает.
Если же запись файла идёт с нормальными символами в заголовке - значит это именно перезапись файла, и её можно проводить.

Ещё про защиту от случайной перезаписи
Чтоб пользователь случайно не перезаписал файл, в котором он из любопытства покопался "блокнотом", и при закрытии согласился сохранить изменения - можно сделать то что писалось в первом посте темы. Файл поступивший для перезаписи должен иметь установленный атрибут "System" (или любую комбинацию из нескольких атрибутов). Но при вычитывании Виндой в кэш содержимого "флешки" - у этого файла таких атрибутов быть не должно (у него должен быть обычный вид). Тогда при случайной перезаписи ПО контроллера не обнаружит установленного атрибута, и проигнорирует такую запись.
А перезаписывать сможет только тот, кто руками устанавливает перед этим комбинацию атрибутов.

Сообщение отредактировал controller_m30 - Oct 21 2016, 10:12

[Allregia]

Ну, на самом деле, если не нужны функции записи данных в файловой системе,

Функции записи именно и нужны.

то остаток (только чтение файлов) это всего лишь 10% от функциональности\размера кода.

Это как раз функции чтения не нужны.
Т.е. прочитать-то можно (т.е. скопировать файл в РС), но данные при чтении принудительно все нулями отдаются.

Если еще жестко завязаться на тип, к примеру FAT12, и отсутствие директорий (кроме root), то разбор этого несчастного фата и чтение данных из cluster chain
займет строк 500 кода с обширными комментариями.

И "разбора ФАТ" процессором тоже не нужно, это просто массив в ОЗУ, заполняемый процессором ОДИН раз при включении (также он при этом заполняет в ОЗУ и бут с рутом).
Вы все-таки не поняли что это и для чего, поэтому продолжаете упоминать FatFs, которая тут никоим боком не нужна и ничем не поможет.

Да, кстати... если ваше устройство прикидывается mass storage и эмулирует FAT FS на лету, может вам на лету и эмулировать root directory вместе с dir. entry ваших хитрых файлов ?

См выше - они формируются один раз при включении питания и запуске бутлоадера.

[gerber]

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

[CrimsonPig]

Вы все-таки не поняли что это и для чего, поэтому продолжаете упоминать FatFs, которая тут никоим боком не нужна и ничем не поможет.

Это у вас проблемы с мировосприятием. "FAT FS" в контекстре моих сообщений, это "FAT file system", то бишь способ организации данных на носителе, соотвествующий спекам FAT file system от MS.
Если вы кроме китайских поделок мало что видели, это ваши проблемы.

[Allregia]

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

Так можно, особенно, если сделать как тут:

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

Но это все несколько сложнее, а главное - овчинка выделки не стоит.
Я уже не рад что задал этот вопрос про ФАТ - я тут сам себя запутал, а проблема оказалась вообще в большей части надуманной, т.е на самом деле ее нет.

то у вас проблемы с мировосприятием. "FAT FS" в контекстре моих сообщений, это "FAT file system",

Оправдываемся?
"FatFs" в контексте этого раздела этого форума, совершенно однозначно означает то что оно означает - библиотеку работы с файловой системой для эмбеддед систем от Чена, а вовсе не:

то бишь способ организации данных на носителе, соотвествующий спекам FAT file system от MS.

Так я это и сделал - предоставил винде бут, фат, рут и "тело" диска, соответствующие спекам от MS, а с файловой системой - работат она а не я.

Если вы кроме китайских поделок мало что видели, это ваши проблемы.

Причем тут "китайские поделки"? FatFs вообще-то японская, а японцы - они генетически корейцы а не китайцы

P.S. И видел я думаю, уж не меньше Вашего, с компами с начала 80-х слава богу, еще с Микро-80.

[jcxz]

Раз это бутлоадер, то все эти танцы с бубнами и ФАТами - лишние. Самый правильный и простой путь: делаете устройство с вендор-специфик интерфейсом, без всяких профилей, через эндпоинты. А на ПК пишете приложение для заливки прошивок и конфигурирования. Ничего лишнего, юзеру удобнее и полный контроль его действий и прошивки и пр.
Для пользователя это в 100 раз удобнее чем все эти танцы с бубнами и костыли. Да и размер бутлоадера меньше будет.

PS: Да и вообще непонятно - как Вы во флешь контроллера пишете при работающем в это время USB-стеке? Вроде обычно во всех МК во время записи во флешь программ, код оттуда выполнять нельзя. Что за МК такой, позволяющий это? Или Вы код USB-стека в ОЗУ разместили?

[XVR]

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

Так что вариант из сообщения 42 (со сквозной нумерацией) это похоже единственное решение, которое будет работать всегда.
Да, и резать по секторам (512 байт) слишком мелко - вполне достаточно по кластерам, сектора в них никогда не перемещаются на другое место относительно самого кластера

Но это все несколько сложнее.

Прочесть 2-4 байта адреса из начала блока данных и записать остаток в FLASH по этому адресу сложно?

[Allregia]

Раз это бутлоадер, то все эти танцы с бубнами и ФАТами - лишние. Самый правильный и простой путь: делаете устройство с вендор-специфик интерфейсом, без всяких профилей, через эндпоинты. А на ПК пишете приложение для заливки

Вот этого и хтелось бы избежать, поэтому и выбран был MSD, как не требующий драйверов и специальных программ.
А программа для изменения настроек - так она одному из ста понадобится, тем более, что их мобно поменять с самого устройства (там есть TFT и кнопки+энкодер).

PS: Да и вообще непонятно - как Вы во флешь контроллера пишете при работающем в это время USB-стеке? Вроде обычно во всех МК во время записи во флешь программ, код оттуда выполнять нельзя. Что за МК такой, позволяющий это? Или Вы код USB-стека в ОЗУ разместили?

Нет. Вообще идея это на моя, я уже упоминал - AN-10866 от NXP для LPC1700. Лкгко гугглиться: https://www.google.co.il/url?sa=t&rct=j...Vbd7ac7IWCsjiIw
У меня это работает уже несколько лет в паре устройств на LPC1768, конкретно сейчас это делается для STM32F103.
Там, где у меня стоит STM32F407 и STM32F767 я этого пока не делал, там бутлоадер, или тоже USB но в хосте, грузится с USB-флешки, или с SD-карточки.

Прочесть 2-4 байта адреса из начала блока данных и записать остаток в FLASH по этому адресу сложно?

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

P.S. Лучше подскажите еще такую вещь - куда сразу смотреть в доки по процам, чтобы понять нужен им или не нужен подтягивающий резистор на Д+? На то, может ли USB был и хостом и девайсом? или на OTG? Но у LPC1768 он OTG/Host/Device, а резистор требует.

Я вот с STM32F103 до этого дел не имел, а из тех что имел - он только LPC1768 нужен был.
В последние годы работал с SM32F407, L151, L467 - им всем он не нужен, так я и для F103 забыл его в пробный вариант платы поставить, пришлось допаивать.

[jcxz]

Вот этого и хтелось бы избежать, поэтому и выбран был MSD, как не требующий драйверов и специальных программ.

Имхо - для юзера куда хуже пляски с бубнами с подключениями/отключениями устройства, отключение кеширования в диспетчере оборудования, какими-то манипуляциями да ещё и несколькими файлами да ещё в определённом порядке их.
И при этом ещё ничего и не гарантируется, что всё равно будет записано неправильно, так как никаких гарантий от винды по поводу порядка записи кластеров нету, хоть сколько Вы у себя отлаживайте и проверяйте, найдётся система где кластера будут писаться в неправильном порядке (хоть сколько это устройство не дёргай). И объясняйте потом юзеру что это он зря порылся в реестре и поставил какие-то опции, или поставил какую-то хитрую прогу кеширования взамен стандартной. В ответ Вас будут спрашивать: А почему другие программы работают нормально, а Ваша - нет?
Маты от "благодарных" юзеров Вам, как разработчику этого велосипеда, гарантированы.
Куда проще - запустить файлик и нажать в нём одну кнопку "прошить". А уж про настройки и говорить нечего.

У меня это работает уже несколько лет в паре устройств на LPC1768, конкретно сейчас это делается для STM32F103.

На LPC17xx стирание сектора флешь занимает вроде около 100мс. В это время все прерывания запрещаются. Ну возможно что USB-протокол (и MSD) устойчив к таким ситуациям....

[YAM]

Это через LUN?

Да.
У меня таким образом сделано обновление прошивки, запись пользовательского скрипта и чтение-запись области eeprom памяти.
Что винда, что linux всегда все пишут последовательно...
Естественно при загрузке я сам заполняю MBR, FAT и DIR для каждого диска. Это всего-то 3 сектора по 512 байт.
В MBR указано что чило копий FAT=1, секторов на элемент таблицы FAT=1 и число элементов в корневом каталоге = 512/32, т.е. занимает всего 1 сектор, использую FAT12.
Размер кластера 2 сектора, т.е. 1024 байта.
Имя в DIR генерю тоже при загрузке причем с версией загруженного приложения, так: YAM-MAINSCRIPT Version 1_23.ldr (это типа файл прошивки)
Метка тома содержит версию загрузчика, а серийный номер диска = собственно серийному номеру устройства.
Все крутится на STM32F105-й и занимает 16 килобайт в загрузчике.
Для обновления прошивки типа удаляем средствами винды файл старой прошивки и записываем новый. Контроллер расшифровывает на лету прошивку посекторно и сразу пишет в область приложения. Естественно файл прошики из устройства не читается , вернее читается, но там одни нули...

[Allregia]

Да.
У меня таким образом сделано обновление прошивки, запись пользовательского скрипта и чтение-запись области eeprom памяти.
Что винда, что linux всегда все пишут последовательно...
Естественно при загрузке я сам заполняю MBR, FAT и DIR для каждого диска. Это всего-то 3 сектора по 512 байт.
В MBR указано что чило копий FAT=1, секторов на элемент таблицы FAT=1 и число элементов в корневом каталоге = 512/32, т.е. занимает всего 1 сектор, использую FAT12.
Размер кластера 2 сектора, т.е. 1024 байта.

У меня все точно также, разве что сектор=кластер=512 байт, ну и диск пока один.
Попробую разобраться с LUN, не пользовался им пока.
Это на каждый диск надо иметь MBR+FAT+Root.
Похоже, два диска через LUN даже проще чем два раздела на одном диске.

Имя в DIR генерю тоже при загрузке причем с версией загруженного приложения, так: YAM-MAINSCRIPT Version 1_23.ldr (это типа файл прошивки)
Метка тома содержит версию загрузчика, а серийный номер диска = собственно серийному номеру устройства.
Все крутится на STM32F105-й и занимает 16 килобайт в загрузчике.
Для обновления прошивки типа удаляем средствами винды файл старой прошивки и записываем новый. Контроллер расшифровывает на лету прошивку посекторно и сразу пишет в область приложения. Естественно файл прошики из устройства не читается , вернее читается, но там одни нули...

Все точно также, только для F103 загрузчик сейчас 6.5К, я для уменьшения не вывожу в нем ничего на дисплей.
На LPC1768 тоже 6.5К занимало: Total ROM Size (Code + RO Data + RW Data) 6568 ( 6.41kB)

[Allregia]

YAM, щiро дякую!

C двумя LUN получилось великолепно, теперь и последний недостаток исчез.
Долго завозился - второй диске не виделся, его размер генерировался автоматом из рамера области памяти + бут-рут-фат, получалось 4К, а винда хочет от 8К.
Поставил размер руками, а незанятые кластеры в фате прописал бэдами.
Теперь оба диска показывают свои области памяти и свободное место на диске =0.
Еще раз спасибо!

[YAM]

YAM, щiро дякую!

C двумя LUN получилось великолепно.....

Я рад что смог помочь...

[Allregia]

Интересно - откуда берется ограничение на мин. размер диска 8К? Я в доках не нашел, везде только максимум упоминается.

[YAM]

Интересно - откуда берется ограничение на мин. размер диска 8К? Я в доках не нашел, везде только максимум упоминается.

Специально сделал диск 4096 байт, нет проблем...

[Allregia]

Странно, я перебрал длину диска от 4К до 8К, т.е от 8-ми до 16-ти секторов (по 512), 8-15 - винда кричала что диск не форматирован, на 16-ти успокоилась
Впрочем, это ни на что не влияющая ерунда.

Специально сделал диск 4096 байт, нет проблем...

А меньше дает? Может потому что кластер у Вас =1024 байта =2 сектора а у меня кластер = 1 сектор = 512 байт?


По идеет, на мин. размер ораничение должно быть бут+рут+фат + 1 кластер для данных.