Как я могу использовать SD-карту для регистрации 16-разрядных данных в 48 ksamples/s?

Фон

Моя плата включает микроконтроллер STM32 с картой SD/MMC на SPI и демонстрационных данных аналога в 48 ksamples/s. Я пользуюсь Библиотекой В реальном времени Keil ядро RTX и ELM FatFs.

У меня есть высокоприоритетная задача, которая собирает аналоговые данные через DMA в блоках 40 образцов (40 x 16 битов); данные передаются через очередь длины 128 (который составляет приблизительно 107 мс демонстрационной буферизации) к второй низкоприоритетной задаче, которая сопоставляет демонстрационные блоки в 2 560-байтовый буфер (это быть кратное и 512-байтовому размеру сектора SD и 40 демонстрационным размерам блока). когда этот буфер полон (32 блока или приблизительно 27 мс), данные записаны в файловую систему.

Наблюдение

Путем оснащения кода я вижу, что каждые 32 блока, данные записаны и что запись берет приблизительно 6 мс. Это поддержано, до (на FAT16) размер файла добирается до 1 МБ, когда операция записи берет 440 мс, на которые прерывается время заливки очереди и вход. Если я форматирую карту как FAT32, размер файла, прежде чем событие 'длинной записи' составит 4 МБ.

То, что размер файла, в котором это происходит изменения между FAT16 и FAT32, намекает мне, что это не ограничение карты, а скорее чего-то, что файловая система делает на  границах на 4 МБ или на 1 МБ, который занимает время.

Также кажется, что мои задачи планируются своевременно, и что время используется в коде ELM FatFs только на уровне 1 МБ (или 4 для FAT32) граница.

Вопрос

Существует ли объяснение или решение? Действительно ли это - проблема FAT, или довольно характерный для кода FatFs ELM, возможно?

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

Мне пришло в голову пробовать оптимизации компилятора для снижения времени записи; это, кажется, имеет эффект, но время записи казалось намного большим количеством переменной. В-O2 я действительно получал файл на 8 МБ, но результаты были непоследовательны. Я теперь не уверен, существует ли прямая корреляция между размером файла и точкой, в которой это перестало работать; я видел, что он перестал работать таким образом в различных длинах файла ни на какой конкретной границе. Возможно, это - проблема производительности карты.

Я далее оснастил код и применил деление побеждать подход. Это наблюдение, вероятно, представляет устаревший вопрос, и все предыдущие наблюдения являются ошибочными или отвлекающими маневрами.

Я наконец сузил его к экземпляру запись мультисектора (CMD25), где иногда "ожидают, готовый" опрос карты берет 174 мс для первых трех секторов из блока 5. Тайм-аут для готового ожидания установлен на 500 мс, таким образом, это было бы счастливо активное ожидание этого долго. Используя CMD24 (единственная запись сектора) многократно намного медленнее в общем случае - 140 мс за сектор - а не просто иногда.

Таким образом, это кажется поведением карты, в конце концов. Я буду пытаться попробовать диапазон карт SD и MMC.

15
задан Peter Mortensen 16 May 2017 в 11:30
поделиться

1 ответ

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

Второе, на что следует обратить внимание, это конфигурация ELM FatF. Многие встроенные файловые системы очень скупы на использование буфера по умолчанию. Я видел один, который использовал один 512-байтовый блочный буфер для всех операций и сканировал определенные транзакции файловой системы. Мы дали ему пару килобайт и дело стало на порядки быстрее.

И то, и другое, конечно же, зависит от того, есть ли у вас больше оперативной памяти.

Третий вариант - предварительно выделить большой файл, а затем просто перезаписать данные во время сбора данных. Это устранило бы ряд дорогостоящих операций по выделению кластера и манипуляциям с FAT.

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

5
ответ дан 1 December 2019 в 05:15
поделиться
Другие вопросы по тегам:

Похожие вопросы: