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

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

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

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

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


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

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

Это через LUN?

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

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



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

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

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

Я недавно делал 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.

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

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


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

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

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

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

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

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


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

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

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