Разработка V4.0 EasyFlash: причины, особенности и реализация

EasyFlash — это моё второе открытое программное обеспечение, которое я разрабатываю самостоятельно. С 2015 года оно официально доступно для использования, и к февралю 2019 года прошло уже более четырёх лет с момента его выпуска. За это время многие разработчики встраиваемых систем из других отраслей связались со мной и сообщили, что они уже внедрили EasyFlash в свои продукты. Это очень приятно, так как это свидетельствует о том, что EasyFlash стал зрелым продуктом, который получил признание в различных отраслях.

1.1 Простота функций, но ограниченная производительность

Многие считают, что функции EasyFlash просты и легко применимы в продуктах. Однако с развитием технологий и растущими требованиями к разнообразию KV, а также к ресурсам MCU (в основном RAM, Flash-хранилище и срок службы Flash), старая версия EasyFlash всё ещё имеет потенциал для улучшения в этих областях. Например:

• Каждый ENV, хранящийся на Flash, также кэшируется в RAM. Хотя это упрощает реализацию, это также занимает много ресурсов RAM.
• Тип значения ENV поддерживает только строки. Если вы хотите сохранить другие типы значений (например, массивы или структуры), это становится более сложным. Хотя я позже разработал open-source программу struct2json для решения этой проблемы, она всё ещё недостаточно удобна.
• При каждом сохранении ENV необходимо перезаписать весь сектор Flash. Таким образом, область в конце сектора, которая не используется, остаётся неиспользованной, что снижает эффективность использования Flash и, следовательно, срок его службы.

1.3 NG версия: начало с нуля

С начала 2017 года я начал работу над улучшением производительности EasyFlash, основываясь на потребностях пользователей. Я постоянно анализировал и пересматривал документацию, а также активно общался с некоторыми энтузиастами сообщества. В конечном итоге было решено, что простое улучшение существующей основы будет иметь слишком много ограничений для реализации функций. Поэтому я решил разработать совершенно новую версию компонента ENV следующего поколения (NG).

Версия NG была почти завершена к концу 2017 года, но у меня не было времени на её разработку. Благодаря поддержке моих родственников, я наконец смог завершить разработку версии V4.0 NG во время отпуска по случаю китайского Нового года в доме моих родителей.

2. Особенности V4.0

• Минимальное использование ресурсов, практически нулевое использование памяти;
• Поддержка любых типов и длин значений ENV, аналогично прямому копированию переменных во Flash;
• Более высокая эффективность операций ENV по сравнению с предыдущими моделями, полное использование оставшегося свободного пространства, значительное снижение количества стираний и времени операций;
• Встроенная поддержка балансировки износа и защиты от потери питания (V4.0 ранее требовала дополнительного пространства Flash);
• Возможность инкрементного обновления ENV, поддержка обновления встроенного программного обеспечения после обновления;
• Поддержка режима хранения больших данных, неограниченная длина, данные могут быть последовательно сохранены в нескольких секторах Flash. Ресурсы, такие как сценарии, аудио и т. д., которые занимают более одного сектора Flash, также могут быть сохранены в ENV;
• Поддержка шифрования данных для повышения безопасности хранения, что является обязательным требованием в эпоху Интернета вещей;
• Поддержка сжатия данных для снижения использования Flash.

3. Реализация

3.1 Алгоритмы

Предположим, что в разделе ENV есть четыре сектора. Ниже мы рассмотрим различные операции с ENV и соответствующие состояния Flash и изменения данных.

3.1.1 Процесс операции ENV1 (обычный режим)

3.1.1.1 Первое использование

При первом использовании EasyFlash проверяет заголовки каждого сектора. Если формат не соответствует требованиям, выполняется полная операция форматирования. После форматирования заголовок каждого сектора записывает текущую информацию о секторе, включая статус, магическое число и другую информацию. Состояние форматирования инициализируется пустым состоянием.

3.1.1.2 Добавление KV1, KV2, KV3

Перед выполнением операции добавления необходимо сначала найти подходящее место для размещения нового KV. Стратегия поиска в основном включает в себя:

• Определение того, достаточно ли свободного места в выбранном секторе;
• Предпочтение использованию секторов в состоянии использования, а затем секторов в пустом состоянии;
• Проверка наличия дубликатов KV и выполнение дополнительных действий по удалению старых значений, если они существуют.

Из рисунка видно, что KV1, KV2 и KV3 были помещены в sector1, и состояние сектора было изменено на используемое.

3.1.1.3 Изменение KV2 и KV3, удаление KV1 и добавление KV4

Во время модификации ENV старое значение ENV будет удалено, а состояние сектора будет изменено на грязное. Затем будет выполнена новая операция добавления ENV.

• При изменении KV2 существующее значение KV2 заменяется на удалённое, состояние sector1 изменяется на грязное, и новое значение KV2 помещается в sector1. Поскольку в sector1 больше нет места, состояние sector1 также изменяется на заполненное.
• При изменении KV3 существующее значение KV3 заменяется на удалённое, а поскольку состояние sector1 уже грязное, никаких изменений не требуется. Новое значение KV3 может быть помещено только в sector2, и после помещения состояние sector2 изменяется на используемое.
• При удалении KV1 существующее значение KV1 заменяется на удалённое, а состояние sector1 уже является грязным, поэтому никаких изменений не требуется.
• При добавлении KV4 после поиска подходящее место для хранения находится в sector2. После добавления состояние sector2 становится используемым, и никаких дальнейших изменений не требуется.

3.1.1.4 Добавление KV5 и KV6, запуск GC

• Операция добавления KV5 требует много места, поэтому она может быть размещена только в новом секторе sector3. После размещения состояние sector3 становится используемым.
• Операция добавления KV6 также может быть размещена только в секторе sector3, и после размещения сектор sector3 заполняется. Запуск GC необходим, поскольку в разделе ENV остался только один пустой сектор.
• Запуск GC инициирует поиск всех секторов, которые помечены как заполненные и грязные. Эти сектора затем перемещаются в другое место. В этом случае KV2 в секторе sector1 перемещается в сектор sector2, освобождая sector1. После перемещения sector1 форматируется, и в разделе ENV снова появляется пустой сектор.

3.1.2 Процесс операции ENV2 (режим большого хранилища данных)

Продолжение следует…

3.2 Структура данных

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

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

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

После завершения проектирования вся структура данных ENV выглядит следующим образом. Эта диаграмма также может быть преобразована в соответствующую структуру данных.