Есть процессор STM32F103RC и память на 2 Мегабайта M25P16.
Хочется получить доступ к памяти через USB, как к диску.

Взял на сайте ST пример реализации mass storage, обрезал обращение к SD карточке, и для начала запустил в качестве памяти буфер на 32К в ОЗУ процессора.
Это работает, диск при подключении определяется, форматируется, файлы пишутся, читаются и стираются.

Нужно делать следующий шаг - перенести буфер во флеш. Для начала - хотя бы во внутреннюю флеш процессора.

И вот тут я "затормозил".

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

Помогите, пожалуйста, кто "в теме".

кроме как кешировать весь сектор 64К в ОЗУ на момент стирания/записи - похоже что никак.

Зачем "весь" и зачем "64К"?
Определяете минимальную порцию данных (страницу) которую может писать/стирать данная флешка (256/512/2048 байт) и все операции записи реализуете через эти страницы. Дальше - обычный write-back буфер страниц в ОЗУ CPU под некоторое кол-во этих страниц с вытеснением при переполнении наиболее старых страниц из ОЗУ во флеш.
И надо ещё предусмотреть сигнал аварии питания, по которому у вас при отключении питания CPU успеет всё содержимое буфера скинуть во флеш. Упреждение прихода сигнала относительно формирования RESET на CPU должно быть достаточным для сброса буфера. Для ускорения этого процесса, можно во флеш предусмотреть необходимое кол-во заранее стёртых страниц для такой аварийной записи (так как запись во флеш без стирания много быстрее чем со стиранием).


Не знаю как для STM32, но по LPC могу сказать что внутренняя флеш - не лучший выбор:
1. На порядок меньший ресурс перезаписи по сравнению с обычными SPI флеш.
2. Неудобный размер минимальных порций записи/стирания. И причём они разного размера.
3. Во время операций записи/стирания нельзя выполнять код из флеш. Соответственно если у вас в это время работает USB стек (и прочие ISR/задачи), то он весь должен быть в ОЗУ.

Минимальный стираемый блок у микросхем M25P** фирмы микрон составляет 64 килобайта.

У M25PE** можно стирать страницы, по 256 байтов.

как раз 64К стирает, см.даташит.

Тогда лучше использовать что-то более удобное: W25X16 (4K), AT45DB161D (512).
Иначе - придётся ставить внешнюю ОЗУ для буфера.
Хотя (так как микросхема флеш всегда будет использоваться вместе с данным ПО доступа к диску) можно придумать и что-то сложно извращённое. Например: иметь таблицу трансляции логических номеров секторов в физические, иметь один дополнительный свободный сектор, при записи некоторой страницы во флеш переписывать весь сектор, который её содержал в свободный сектор, корректировать таблицу трансляции и очищать старый сектор, объявляя его свободным. Таблицу трансляции надо сохранять в эту же флеш при сбое питания.
Или более сложный алгоритм типа как в SSD-дисках.

Спасибо отвечавшим, всё внимательно прочитал, и даже сам пытался думать.
Надумал вот что попробовать:

- сделать в RAM буфер размером с таблицу FAT.
Запись и чтение в сектора, принадлежащие FAT - перенаправлять в этот буфер.
Запись собственно данных - направлять сразу в M25P16.
А спустя одну-две секунды после окончания записи - переписывать FAT из RAM в M25P16, стирая предварительно сектор (64К).
Так как использоваться в качестве mass storage устройство будет очень редко, то это вполне допустимо.

Обязуюсь доложить результаты.


К сожалению, нельзя. Только 64К.

Не понял, почему или кому нельзя. На всякий случай - кусок из технического описания.

Не, железо менять не будем



Именно так: - "сложно извращённое", и с учётом реальных потребностей.





M25P16 нельзя.

Купите втихаря M25PE16, перепаяйте втихаря, документацию откорректируйте, и - вперед!

Минимум, что можно стереть - 64К.



Не, это не требуется. Mass storage - не основной режим, очень редкое использование.



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

Если вы говорите что железо менять нельзя, то у вас в устройстве значит уже должна быть внешняя память.
Либо использовать предложенный мной метод с таблицей трансляции логических номеров кластеров в физические.
Иначе - как вы собираетесь переписать один кластер во флеш с учётом того, что стирать можете только по 64К?
Размер кластеров в вашем FAT какой? 512 или...?
Либо внешняя память и тогда - считываем сектор, стираем его, заменяем изменившиеся кластеры в нём, записываем.
Либо используем таблицу трансляции - тогда не нужен большой буфер в ОЗУ и можно обойтись внутренней ОЗУ CPU.
Но таблицу трансляции надо скидывать по сигналу сбоя питания (это тоже должно быть уже в железе).
Если у вас чего-то из этого в железе нет, то его менять придётся всё равно и лучше заменить микросхему флеш на что-нить более удобное.

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

Из внешней памяти в устройстве только M25P16. Устройство в таком виде свои задачи выполняет. В памяти ( M25P16 ) записаны голосовые сообщения, одним "куском" немного больше мегабайта. Файловой системы в устройстве нет. Звук записывается один раз при изготовлении, через технологический UART по протоколу X-modem, медленно и печально.
Речь идёт о модификации - ускорении этой загрузки. И - как дополнительный бонус - дать возможность заказчику обновлять звук при эксплуатации.

Размер кластера, насколько я понимаю, мне виндовс задаст при форматировании.
Хм... А что, если мне самому "отформатировать" диск? Задать размер кластера 64К, тогда у меня вся таблица FAT будет крошечная. Виндовсу форматирование - запретить.
Надо попробовать.

С таблицей трансляции как-то сложновато по моему. Да и, признаться, не очень понятно как.
Отследить потерю питания ТЕОРЕТИЧЕСКИ можно, но это "не вариант". При записи файла питание устройства будет, скорее всего - от USB. Время, в течении которого имеющиеся электролиты разрядятся с 5 до 3 вольт слишком мало. Но вполне можно сделать сохранение таблицы трансляции через 1-2 секунды после последней операции со стороны виндовс.

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

Нечто похожее есть в примерах NXP "USB bootloader".

И зачем тут файловая система?
И уж точно она никак не поможет ускорить загрузку.
По-моему вы необоснованно усложняете задачу.

В FAT16 максимальный размер кластера ==32К. Учите матчасть
И маленькие файлы тогда будут занимать очень много места.

У вас нет ОЗУ, достаточного для хранения 64К. И как вы при этом собираетесь перезаписывать отдельные области (кластера) внутри этих 64К, объясните?

Какой тогда вообще смысл в FAT?

Всё, полез искать пример. Это решение - было бы для меня идеальным! Именно то, что мне нужно!


Мне она не нужна. Но без неё виндовс не может.

Сама по себе файловая система - конечно нет. Но загрузится файл всё же быстрее, чем через UART 115200.

Эт точно!

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

Легкий доступ из виндовс, больше ничего.

Докладываю: - проблема решена.

Выглядит это так: - во флеш памяти прцессора лежит 3 массива констант :
- 512 байт - загрузочный сектор
- 112 байт - FAT
- 160 байт - корневой каталог.

Эти массивы "скармливаются" виндовсу, когда он читает соотв. адреса.
При чтении выше 20К - происходит реальное чтение из m25p16
Когда виндовс пишет по адресам ниже 20К - не делается ничего.
Запись выше 20К направляется в m25p16.
При записи в первый сектор страницы 64К - сначала вызывается процедура стирания страницы.

В итоге получилось вот что:
- При подключении устройства, в виндовс появляется новый диск, на котором уже есть файлы ( у меня их там 4 штуки).
- Эти файлы можно перезаписывать, не меняя имён.
- Нельзя стирать ПЕРЕД записью - тогда новый файл может попасть по другим адресам, и всё поломается (но восстановится после сброса)!
- Диск нельзя "убить" никаким форматированием (но данные стереть можно).
-Загрузка файла происходит раз в 5 быстрее, чем было раньше.

В общем, поставленные задачи полностью выполнены.
Спасибо всем, кто помогал. Особенно ценной была подсказка esaulenka - за что отдельное спасибо!