[HardEgor 66]

Именно так и было сделано, пока файл был один.

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

Эти два файла занимают все место на диске, точнее - диск выглядит размером с суммарный размер обоих файлов.

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

[Allregia 9]

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

 

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

[sigmaN 0]

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

Эти костыли вас не смущают?

[YAM 0]

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

 

[Allregia 9]

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

Эти костыли вас не смущают?

 

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

 

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

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

[YAM 0]

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

При чем тут MBR к двум дискам?

Не 2 раздела на одном диске, а 2 диска.

 

[Allregia 9]

При чем тут MBR к двум дискам?

Не 2 раздела на одном диске, а 2 диска.

Это через LUN?

[sigmaN 0]

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

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

 

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

 

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

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

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

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

[Allregia 9]

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

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

 

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

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

 

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

[CrimsonPig 0]

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

 

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

Или сейчас опять откроется пачка секретных требований, которые некто утаил в силу своей хитрости ?

 

 

[Allregia 9]

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

 

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

[controller_m30 1]

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

Вроде бы здесь о похожем говорят :rolleyes: В общем приведу по памяти, вдруг то что надо.

 

При перезаписи переменного файла (например он назывался 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 я сейчас точно не помню, какие временные поля, и в какой очерёдности переписываются. Помню только что их три: дата создания, дата модификации, и дата открытия. И вроде бы, оно три раза те поля и переписывает. Почему это делается в три приёма (а не за один раз) я не помню. Вроде бы поле "дата модификации" несколько раз переписывается... зачем-то... Не помню :laughing:

Чтения секторов при этом процессе вообще нет. Как считала Винда всё в кэш при подключении, так из кэша все сведения и черпает: и FAT1,2 и Root.

[sigmaN 0]

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

Ну послушайте, раз эти файлы с компа могут переписываться до для чего-то это нужно! Следовательно дальше ваш девайс эти файлы таки использует каким-то образом! Это очеивдно!

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

 

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

 

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

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

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

 

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

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

Мне кажется это будет единственный способ сделать это без костылей.

[Ruslan1 16]

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

 

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

 

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

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

 

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

 

 

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

[sigmaN 0]

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

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

 

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