Если вкратце, то нет пути засинхронизировать наше устройство с кешем ОС. Поэтому о динамике речи не идёт. Изменения ФС возможны только перед перед её монтированием.
Но в API со стороны хоста же есть обычно команды сброса файлового кеша?
Сброс файлового кеша (flush) заставит вылить на носитель отложенные для записи данные. Что нам не интересно.
Если же сбрасывать кеш всей файловой системы (если это возможно) — то это равносильно перемонтированию ФС или передёргиванию USB, что приведёт к гигантскому накладному расходу, т.к. драйвер ФС тот час же перечитает несколько кластеров (FAT таблица и корень). В этом случае — да, мы можем менять ФС на устройстве в динамике. Но это путь злодея.
как файловые менеджеры в риалтайме(или почти) могут видеть изменения размеров файлов
Двумя способами:
1. Специфическое API нотификации файловой системы.
2. Периодическое чтение файлового каталога с мониторингом изменений.
В обоих случаях работа программы происходит с драйвером ФС и его кешем, и лишь редкий вызов будет транслироваться в реальное чтение носителя.
решить проблему превращением устройства в независимое сетевое
Увы, красивого способа это сделать нет. По причине кеширования ФС операционной системой. Даже если мы изменим ФС на устройстве, вряд ли есть способ сообщить об этом хосту. Повторное чтение файла с устройства с большой вероятностью будет происходить уже из кеша ФС, а не с нашего устройства.
Напрашивающийся выход — это, действительно, CDC интерфейс (COM-порт).
Если Вам понадобится стабильный CDC (или MSC+CDC) для stm32f4 — обращайтесь, было дело, переписывал stm-ый драйвер как раз по причине той самой кривости (отсутствие flow-контроля, гигантизм roll-back буффера, отсутствие обработки кратности bulk-пакета).
Да, так можно и даже нужно делать!
Для этого нужно:
— при подключении USB рассчитать (и записать в таблицу) конечный размер файла, после чего вызвать init.
— в колбэке чтения формировать ту часть файла, которую запрашивает библиотека
Только нужно учесть, что целевые данные не должны меняться, когда МК находится в режиме Mass Storage.
Иначе хост прочитает часть «старых» и часть уже изменённых данных в одном файле.
Сам эмулятор, как и говорил, кроссплатформенный, сложностей возникнуть не должно. Однако драйвер USB-MSC придётся, само собой, запускать нативный для PIC-а. Если займётесь — будет интересно понаблюдать! Допускаю, что могут возникнуть проблемы в части директивы выравнивания или из-за другой специфики PIC компилятора.
Сброс файлового кеша (flush) заставит вылить на носитель отложенные для записи данные. Что нам не интересно.
Если же сбрасывать кеш всей файловой системы (если это возможно) — то это равносильно перемонтированию ФС или передёргиванию USB, что приведёт к гигантскому накладному расходу, т.к. драйвер ФС тот час же перечитает несколько кластеров (FAT таблица и корень). В этом случае — да, мы можем менять ФС на устройстве в динамике. Но это путь злодея.
Двумя способами:
1. Специфическое API нотификации файловой системы.
2. Периодическое чтение файлового каталога с мониторингом изменений.
В обоих случаях работа программы происходит с драйвером ФС и его кешем, и лишь редкий вызов будет транслироваться в реальное чтение носителя.
А вот это красиво и современно )
Напрашивающийся выход — это, действительно, CDC интерфейс (COM-порт).
Если Вам понадобится стабильный CDC (или MSC+CDC) для stm32f4 — обращайтесь, было дело, переписывал stm-ый драйвер как раз по причине той самой кривости (отсутствие flow-контроля, гигантизм roll-back буффера, отсутствие обработки кратности bulk-пакета).
Для этого нужно:
— при подключении USB рассчитать (и записать в таблицу) конечный размер файла, после чего вызвать init.
— в колбэке чтения формировать ту часть файла, которую запрашивает библиотека
Только нужно учесть, что целевые данные не должны меняться, когда МК находится в режиме Mass Storage.
Иначе хост прочитает часть «старых» и часть уже изменённых данных в одном файле.