Для тестирования выбрана аппаратная платформа на базе чипа STM32H753VIH с частотой ядра 480 МГц. Подключение к SD карте выполнено через интерфейс SDMMC с частотой 60 МГц. В качестве драйвера работает стандартная библиотека STM32H7xx_HAL. Используется промежуточное программное обеспечение FileX из пакета Azure RTOS поддерживающее exFAT.
Мотивация
В малых встраиваемых системах спецификации и параметры SD карт от производителей не дают ответа о том как будет происходить запись и чтение в реальном приложении и в реальном времени. Имеют значение многие факторы: это и свойства самих SD карт, и свойства драйверов периферии, свойства операционной системы, свойства файловой системы, особенности архитектуры приложения и взаимодействия задач и т.д. и даже риски приобретения некачественных карт. В таких условиях неизбежно приходится прибегать к тестированию. Значит нужен постоянный инструмент для такого тестирования.
Обычно я вставлял в свои проекты программные модули тестирования записи-чтения SD карт с интерактивным управлением через терминал по последовательному каналу связи. Канал делал через UART. Но это медленно. Терминал не предоставляет удобных средств визуализации. При этом вся обработка и статистика должна быть реализована в самом устройстве.
Теперь же я решил перенести сбор статистики и визуализацию на PC. Физический канал сделать на USB, поверх него установить канал TCP/IP и над всем этим несколько прикладных протоколов. Немного об этом здесь. В качестве среды разработки и визуализации очень удобен оказался MATLAB.
MATLAB, а вернее среда графического программирования SIMULINK позволяет моментально визуализировать любые сигналы и переменные, быстро менять алгоритмы обработки данных и рефакторить в целом всю структуру проекта.
Теперь тестирование SD карт занимает гораздо меньше места в памяти устройства, выполняется быстрее, и даёт гораздо больше информации.
Тест помимо прочего показывает стабильность всей программной платформы включая RTOS, файловую систему, сетевой стек и стек USB.
Аппаратная платформа для тестирования
Для тестирования применяется плата полифункционального зарядника. Предполагается оснастить зарядник AI алгоритмом, поэтому нужен этап накопления больших данных. Данные будут накапливаться на SD карту. И от качества работы SD карты многое зависит.
На нашей плате есть разъем для microSD карт. Используется 4-битный интерфейс SDIO с тактовой частотой 60 МГц и напряжение питания 3.3 В. Такая частота несколько выше допустимой при напряжении 3.3 В, но перегрева карты не возникает. Сами тестируемые карты как правило допускают большую частоту тактирования, но при меньших напряжениях питания. Максимальная скорость обмена в такой конфигурации могла бы быть 30 мегабайт в сек. И тесты где-то к такой скорости приближаются.
На PC скорость чтения тестируемых карт превышала 90 Мбайт в сек.
Программная платформа
Программная платформа основана на проекте Azure RTOS. Более подробно было в этой статье. Тогда ещё не было портировано программное обеспечение для поддержки exFAT. Как известно, exFAT даёт возможность работать с SD картами размером больше 32 Гбайт. А в тесте применяются карты размером 64 Гбайт.
В представленном проекте уже портирован программный модуль filex с поддержкой exFAT.
Связь со средой SIMULINK, находящейся на компьютере, осуществляется через физический интерфейс USB, поверх которого работает сетевой протокол TCP/IP. Т.е. помимо filex применяются программные модули usbx и netxduo из пакета Azure RTOS.
Очень важно, что параллельно с выполнением теста на плате продолжает выполняться основное приложение управления зарядником (АЦП, SPI, GUI, HMI и проч.). Поскольку именно в таких условиях будет вестись работа с SD картой. Такая организация позволяет получить результаты максимально соответствующие конкретному применению, хотя и неопределённо отдалённые от наилучших показателей. Но задача работы с SD картой при этом получает наивысший приоритет во время теста.
Модель SIMULINK для тестирования непрерывной записи блоков в файл
Первым сценарием для теста принимаем непрерывную запись в открытый файл блоков фиксированной длины. Такой сценарий характерен для логгеров процессов и сигналов в реальном времени.
В малых встраиваемых системах всегда мало оперативной памяти и поэтому записываемые блоки в них не могут быть слишком большими. Однако если размер блока будет слишком маленьким, то скорость записи снизится на порядок по сравнению с максимально достижимой на данной аппаратной платформе. В своих системах я принял за оптимальный размер блока 32768 байт. Это число кратно 512 байтам и значит не будет вызывать торможения в драйвере HAL.
Верхний уровень модели прост и в нем настраивается два параметра теста: размер блока и максимальное количество блоков.
При запуске модели сначала будет выполнена подсистема "Передатчик команды". Эта подсистема передаёт пакет с командой устройству по протоколу TCP/IP. После этого начинает выполняться подсистема "Обработчик данных".
По достижении максимального количества выполнение модели остановится. Остановить выполнение модели в SIMULINK можно и в ручную, не дожидаясь её автоматической остановки и пользоваться частичными результатами.
Подсистема "Передатчик команды" формирует простейший пакет из нескольких полей. В начале пакет находится поле идентификатора команды. В конце пакета находится значение 16-битной контрольной суммы в виде CRC-16/XMODEM . Наличие CRC требуется не столько для проверки целостности команды, как для того чтобы устройство не получило ложную команду от компьютера. Так как подключаясь к компьютеру по TCP/IP мы рискуем получать от него массу служебных пакетов от сторонних приложений.
Подсистема "Обработчик данных" содержит приемник TCP пакетов, узел контроля окончания теста, вычислитель статистики, индикаторы текущих результатов и подсистему сохранения результатов в рабочее пространство MATLAB. В рабочем пространстве результаты выводятся виде таблицы и их удобно копипастить в Excel для последующей презентации.
Вычислитель статистики получаемых результатов был оформлен в виде подсистемы, поскольку много раз в модели пере используется.
В нем вычисляется среднее по потоку результатов тестов, максимально и минимальное значение. Иногда хочется видеть статистическое распределение результатов. Для этого вставлен блок построения гистограммы. В дальнейшем выяснилось, что распределение длительности операций с SD картами далеко от случайного и рассматривать гистограммы стало не так интересно. Однако блок оставлен, чтобы потом если понадобиться не искать его долго в палитре.
Модель SIMULINK для тестирования записи-чтения-стирания файлов
Эта модель не намного сложнее, но в результате выполнения создает больше данных поскольку здесь измеряются длительности: открытия файла на запись, записи , закрытия файла, открытия на чтение, чтения, удаления. Все эти длительности важно знать для систем работающих в реальном времени. Запись файлов ведется в корневую директорию SD карты. Именам файлов присваивается порядковый номер.
В управляющей команде появились новые поля. Флаг "Разрешение чтения" указывает на то, что после записи файл следует прочитать и проверить целостность данных. Если флаг в состоянии false, то чтение производится не будет, длительности операций чтения измеряться не будут, но ускорится выполнение теста. Также флаг удаления файла в состоянии false приведет к тому что файлы после записи не будут удаляться и также не будет измеряться длительность операции удаления. Такой режим интересен для определения степени деградации времени открытия файлов при их большом количестве в корневой директории.
Обработчик данных дополнился вычислителями статистик новых переменных.
Блокирующий или не блокирующий приём TCP пакетов в SIMULINK
Хотя SIMULINK предоставляет огромные возможности и поднимает эффективность разработки алгоритмов до небывалых высот, но в нем как и любом языке есть масса неопределенностей поведения в тех или иных ситуациях. Приведу здесь один пример.
Некоторая путаница возникает с блоком приемника данных по TCP/IP. В нем можно поставит галочку блокирующего режима, или убрать галочку блокирующего режима.
На первый взгляд кажется, что блокирующий режим нежелателен, поскольку вызовет остановку модели пока не будет принят подходящий пакет, мы не сможем выполнять другие алгоритмы параллельно.
Если сделать неблокирующий режим, то модель выглядела бы как показано ниже. У приемника пакетов появился бы строб Status, говорящий о наличии пакета. Мы бы вызывали обработчик данных по триггеру от этого строба. Но оказывается, что строб может быть выдан однократно, а пакетов при этом принято несколько. Но сколько обработчик сигналов понять простыми средствами не сможет, без значительного усложнения подсистемы обработчика.
Таким образом проще применять блокирующий режим приемника данных, но разместить его внутри подсистемы обработчика данных. Там этот приемник заставит подсистему обрабатывать каждый пакет на новом такте не пропуская тактов.
Результаты тестов
Проводилось тестирование 4-х разных SD карт одного производителя. Перед тестирование карты полностью форматировались со стиранием секторов. К результатам надо относится как к статистике и понимать что они были получены для специфичного программного и аппаратного окружения. В любом случае разработчик на своей платформы должен выполнять тестирование заново. Именно для этой цели проект открыт и доступен для неограниченной модификации.
Результаты тестирования тех же SD карт на PC
Тестирование проводилось с помощью программы CrystalDiskMark
Как видно результаты тестирования на компьютере слабо коррелируют с результатами тестирования на встраиваемом устройстве. Если на компьютере видна радикальная разница в скорости записи между SD карты разного класса, то в устройстве она практически не видна и даже в некотором роде наблюдаются обратные результаты.
Это можно объяснить более высокой скоростью тактирования применяемой на PC, наличием кэширования и более продвинутыми драйверами. Это ещё раз доказывает необходимость тестирования SD карт именно на целевой платформе, на которой будут применяться карты.
Итоги
Итак, не написав ни единой строчки кода на PC был получен удобный и гибкий инструмент тестирования файловой системы и SD карт.
Конкретно по результатам можно сделать следующие выводы:
Класс SD карты ничего практически не говорит о том с какой задержкой записи мы можем столкнуться на встраиваемом устройстве с обычным 3-вольтовым SDIO интерфейсом.
Изменение параметра Allocation Unit Size (AU) при форматировании не приводит к заметным изменениям при тестировании. Но карты с AU более 1024 KiB FileX не читает.
Средняя скорость записи на более старые карты может быть даже выше чем на карты класса Video Speed Class 30. Поскольку очень быстрые новые карты во много полагаются на специфику скоростных специализированных програмно-аппаратных драйверов хоста.
Тестирование карт на PC ничем не поможет в выяснении преимуществ карт на встраиваемой системе.
На картах с большим количеством файлов, более 1000, на порядки увеличивается время открытия файла.
Даже карта класса Video Speed Class 30 не дает гарантий записи без потерь блоков размером 32 Кбайт на скорости выше 600 Кбайт в сек. 300 Кбайт в сек - максимальная безопасная скорость для системы в реальном времени. Если нужна большая скорость нужно подключать несколько SD карт одновременно.
Весь проект можно найти здесь. Модели SIMULINK находятся тут.
А здесь файл Excel c результатами тестирования.
Да, и для тех кому решение с MATLAB покажется неприемлемым. В программе устройства по прежнему есть возможность запустить тесты SD карт через терминал. Это реализовано здесь. Вход в терминал через Telnet, скрипт запуска тут. Используется, как можно догадаться, терминальная программа Tera Term.
