Миграция с FatFS на LittleFS: уроки архитектурных просчетов и роль MTP
Приветствую! Я Андрей, технический директор компании “КЕДР Солюшенс”. Коллеги по цеху знают: не стоит изобретать колесо там, где есть проверенные решения. Однако наш опыт в одном из недавних проектов показал, что даже «золотые стандарты» могут завести в тупик, если архитектура выбрана без учета специфики задачи. Сегодня я расскажу о наших ошибках при работе с хранилищем данных и о том, как мы искали оптимальный путь выхода из ситуации.
Точка отсчета
Один из текущих проектов нашей команды — разработка графического калькулятора. Функционал требовал хранения пользовательских данных, конфигураций и результатов вычислений, причем с возможностью управления этими файлами через компьютер.
Выбранный нами стек:
-
Микроконтроллер GD32F470 (240 МГц);
-
Внешняя SPI NOR флеш-память объемом 8 МБ;
-
Интерфейс USB Full Speed.
Для работы с памятью мы выбрали классическую FatFS от ChaN. Она компактна (всего 7 КБ), универсальна и позволяет использовать единый API. Изначально мы реализовали доступ через Mass Storage: при подключении к ПК калькулятор переходил в режим «накопителя», предоставляя прямой доступ к файловой системе для записи прошивки или работы с файлами. Казалось, решение идеальное, но оно стало фундаментом для будущих проблем.
Снежный ком технических сложностей
Изоляция критических данных
Вскоре стало понятно, что пользователь не должен менять системные файлы (историю операций, настройки). Мы выделили 256 КБ под «сырые» RAW-данные, отрезав их от файловой системы. Это решение принесло массу неудобств: усложнение кода, невозможность адекватной эмуляции на ПК, жесткие лимиты по объему и неэффективное использование памяти, когда «сырой» раздел простаивал.
Доступ к файлам «на лету»
Заказчик потребовал управлять файлами без остановки работы устройства. Mass Storage здесь не подходил — он требует монопольного доступа к носителю. Пришлось городить огород: внедрять CDC-ACM (эмуляция COM-порта), писать кастомный протокол на базе Protobuf и разрабатывать десктопное приложение на Qt. В результате мы получили зависимость от сторонних драйверов, проблемы с поддержкой разных ОС и постоянные «танцы с бубном» из-за рассинхронизации версий протокола.
Проблемы производительности и неэффективная запись
Изначальная архитектура предполагала перезапись всех данных при выключении устройства. По мере накопления истории и таблиц время «парковки» выросло до критических 6–7 секунд. Фрагментация внутри FatFS приводила к потере места из-за выравнивания по кластерам: небольшие файлы занимали непропорционально много пространства.
Переход на LittleFS
LittleFS стала нашим спасением: она устойчива к сбоям питания, поддерживает выравнивание износа (wear leveling) и не страдает от «кластерного расточительства». Мы отказались от RAW-разделов — теперь все данные живут в файлах, которые занимают ровно столько места, сколько нужно.
Однако новая ФС потребовала адаптации:
-
Размер кода: LittleFS сложнее FatFS, что стало проблемой для маленького загрузчика (64 КБ).
-
Поиск файлов: Распределенная структура требует оптимизации запросов. Пришлось отказаться от лишних проверок типов в пользу получения метаданных «за один проход».
-
Работа с метаданными: Переименование файлов в LittleFS — дорогая операция. Мы перешли на создание файлов с инкрементным именем и использование индексного файла, что ускорило работу.
Финал: MTP вместо Mass Storage
LittleFS «непонятна» для настольных ОС в режиме Mass Storage. Мы решили эту проблему, перейдя на протокол MTP. В отличие от сырого доступа к блокам памяти, MTP работает через API. Это дало нам гибкость: можно разграничить права доступа (Read-only/Read-Write), обеспечить работу с файлами «на лету» без размонтирования и реализовать собственные расширения (vendor-специфичные команды).
Реализация потребовала порта библиотеки TinyUSB на GD32 и тщательной отладки через Wireshark и 010 Editor. Оказалось, что даже такие мелочи, как выравнивание структур данных, могут сломать весь протокол, если не учесть специфику компилятора.
Итоги
Сейчас проект работает стабильно. MTP решил проблему доступа к данным без потери надежности файловой системы. Мы продолжаем оптимизировать код под размер загрузчика и готовимся полностью заменить эмуляцию COM-порта на развитый MTP-интерфейс, что позволит удобно управлять всеми аспектами калькулятора — от настроек до создания скриншотов экрана.
