Фон
Моя плата включает в себя микроконтроллер STM32 с SD / MMC на SPI и образцыаналоговые данные на скорости 48 кГц / с.Я использую ядро Keil Real-time Library RTX и ELM FatFs .
У меня есть задача с высоким приоритетом, которая захватывает аналоговые данные через DMA в блоках по 40 выборок (40 x 16 бит);данные передаются через очередь длиной 128 (что составляет около 107 мс буферизации выборки) во вторую задачу с низким приоритетом, которая объединяет блоки выборки в буфер размером 2560 байт (это кратно как 512-байтовому размеру сектора SD, так иРазмер блока 40 образцов).когда этот буфер заполнен (32 блока или около 27 мс), данные записываются в файловую систему.
Наблюдение
Набирая код, я вижучто каждые 32 блока данные записываются и что запись занимает около 6 мс.Это будет продолжаться до тех пор, пока (на FAT16) размер файла не достигнет 1 МБ, когда операция записи занимает 440 мс, и к этому времени очередь заполняется, а запись в журнал прерывается.Если я отформатирую карту как FAT32 , размер файла до события «длинная запись» будет 4 МБ.
Тот факт, что размер файла, при котором это происходит, изменяется между FAT16 и FAT32подсказывает мне, что это не ограничение карты, а то, что файловая система делает на границах 1 МБ или 4 МБ, что требует дополнительного времени.
Также кажется, что мои задачи планируются всвоевременно, и то, что время потребляется в ELM FatFs код только на границе 1 МБ (или 4 для FAT32).
Вопрос
Есть объяснение или решение?Является ли это проблемой FAT или, скорее, специфичной для кода ELM FatFs?
Я рассмотрел вопрос об использовании нескольких файлов, но по моему опыту FAT не очень хорошо обрабатывает большое количество файлов в одном каталоге, и это простопотерпеть неудачу также.Возможно, вообще не использовать файловую систему и записать данные на карту памяти, но в идеале я хотел бы прочитать данные на ПК со стандартными драйверами и без специального программного обеспечения.
Мне пришло в головупопробуйте оптимизацию компилятора, чтобы сократить время записи;это, кажется, оказывает влияние, но время записи казалось намного более переменным.В -O2 я получил файл 8 МБ, но результаты были противоречивыми.Теперь я не уверен, существует ли прямая корреляция между размером файла и точкой, в которой он терпит неудачу;Я видел, как он терпел неудачу таким образом при различной длине файла без какой-либо конкретной границы.Может быть, это проблема с производительностью карты.
Я далее инструментировал код и применил подход «разделяй и властвуй».Это наблюдение, вероятно, делает вопрос устаревшим, и все предыдущие наблюдения являются ошибочными или красно-сельдями.
Я наконец сузил его до экземпляра многосекторной записи (CMD25), где иногда "ожидание готово" опросаКарта занимает 174 мс для первых трех секторов из блока 5. Время ожидания для готовности ожидания установлено на 500 мс, так что она будет счастливо занята - ждать это долгое время.Использование CMD24 (односекторная запись) итеративно в намного медленнее в общем случае - 140 мс на сектор - а не просто время от времени.
Так что, похоже, поведение карты в конце концов все же.Я постараюсь попробовать ряд карт SD и MMC.