Моя доска содержит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 МБ, что требует дополнительного времени.

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

Есть ли объяснение или решение? Это проблема FAT, или, скорее, специфичная для кода ELM FatFs?

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

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

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

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

Так что, похоже, поведение карты в конце концов. Я постараюсь попробовать ряд карт SD и MMC.