[gerber 8]

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

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

[Allregia 9]

недавно делал 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 0]

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

[Allregia 9]

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

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

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

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

[sigmaN 0]

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

 

P.S.

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

[Kabdim 0]

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

Ну смотрите, у вас новая схема:

редактор настроек -> файл -> заливка на флешку

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

[Allregia 9]

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

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

Ну смотрите, у вас новая схема:

редактор настроек -> файл -> заливка на флешку

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

Меньше ошибок.

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

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

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

 

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

 

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

[Kabdim 0]

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

[CrimsonPig 0]

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

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

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

займет строк 500 кода с обширными комментариями.

 

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

[controller_m30 1]

По поводу защиты от удаления, но не перезаписи.

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

Если же запись файла идёт с нормальными символами в заголовке - значит это именно перезапись файла, и её можно проводить.

 

Ещё про защиту от случайной перезаписи :rolleyes:

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

А перезаписывать сможет только тот, кто руками устанавливает перед этим комбинацию атрибутов.

Изменено 21 октября, 2016 пользователем controller_m30

[Allregia 9]

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

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

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

Это как раз функции чтения не нужны.

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

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

займет строк 500 кода с обширными комментариями.

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

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

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

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

[gerber 8]

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

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

[CrimsonPig 0]

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

 

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

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

 

[Allregia 9]

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

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

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

Но это все несколько сложнее, а главное - овчинка выделки не стоит.

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

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

Оправдываемся? :)

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

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

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

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

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

 

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

[jcxz 184]

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

Для пользователя это в 100 раз удобнее чем все эти танцы с бубнами и костыли. Да и размер бутлоадера меньше будет.

 

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