Проблемка с записью данных в файл, stm32+cubeF2+fatfs+usb Опции

[XWoo]

Доброго времени суток, коллеги.
Наблюдаю следующую вещь. В цикле идёт периодическая запись одного байта в файл. Данные пишутся без проблем. Но если поставить для отладки светодиод в этот цикл, то по осциллограмме получается следующее: несколько раз светодиод моргает с одинаковой задержкой, а один раз эта задержка в несколько раз увеличивается. Задержка получается именно в функции записи в файл (f_printf или f_puts). Если закомментировать эту функцию, то моргание светодиода становится равномерным!
Пробовал писать массив размером 64,128,256,512,1024,2048,4096 байт - ничего не меняется.

Я использую кейл и библиотеку stm32cubef2. В ней есть пример с использованием usbhost и файловой системы fatfs (от chanа) для записи/чтения строки в файл на usb-флэшку. Я заменил fatfs на последнюю версию с сайта автора - всё повторяется. Пробовал работать с разными флэшками на 4 и 8 Гбайт - задержка всё равно есть.

Есть ли решение этой проблемки? Как с этим бороться? Можно ли это задержку убрать или хотябы уменьшить?

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

Может это такая особенность библиотеки, драйверов или самой fatfs ?

Сообщение отредактировал XWoo - Oct 20 2015, 14:08

[CrimsonPig]

Наблюдаю следующую вещь. В цикле идёт периодическая запись одного байта в файл. Данные пишутся без проблем. Но если поставить для отладки светодиод в этот цикл, то по осциллограмме получается следующее: несколько раз светодиод моргает с одинаковой задержкой, а один раз эта задержка в несколько раз увеличивается. Задержка получается именно в функции записи в файл (f_printf или f_puts). Если закомментировать эту функцию, то моргание светодиода становится равномерным!
Пробовал писать массив размером 64,128,256,512,1024,2048,4096 байт - ничего не меняется.
Я использую кейл и библиотеку stm32cubef2. В ней есть пример с использованием usbhost и файловой системы fatfs (от chanа) для записи/чтения строки в файл на usb-флэшку. Я заменил fatfs на последнюю версию с сайта автора - всё повторяется. Пробовал работать с разными флэшками на 4 и 8 Гбайт - задержка всё равно есть.
Есть ли решение этой проблемки? Как с этим бороться? Можно ли это задержку убрать или хотябы уменьшить?

Проблемы как таковой нет есть небольшое непонимание некоторых вещей:

- никто не знает (и все может поменяться в любой версии софта), как реализованы высокоуровневые функции над файловой системой (fprintf и им подобные). Как они кешируют данные для записи\чтения и когда решают эти кеши скинуть в файловую систему. Никаких гаранитий по времянкам тут нет.

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

- запись на носители с NAND флэшем никаких особых гарантий по времянкам не дает, поскольку унутре оно в любой момент может начать процесс освобождения erase blocks.

Так что рассчитывать на какие-то конкретные задержки и их отсутствие не стоит.. Можно с грехом пополам рассчитывать на какую-то среднюю производительность, да и то не всегда.
В консерватории надо править, то есть сам высокоуровневый подход к работе с данными.

[esaulenka]

- никто не знает (и все может поменяться в любой версии софта), как реализованы высокоуровневые функции над файловой системой (fprintf и им подобные). Как они кешируют данные для записи\чтения и когда решают эти кеши скинуть в файловую систему. Никаких гаранитий по времянкам тут нет.

Вообще говоря, fprintf - штука довольно очевидная. Легко изучается, легко подменяется на свой велосипед. Времянки по ней посчитать тоже очень легко (хочешь в тактах, хочешь - осциллографом), и они достаточно стабильные. Разговор "всё может САМО поменяться" вообще ни о чём, с чуть меньшей вероятностью Земля завтра налетит на небесную ось.

А вот ST'шная библиотека хоста - штука довольно странная. Изучать её можно долго, там наверчено хрен знает что. Можно ли это как-то значительно оптимизировать - не знаю... Бесплатных аналогов этой библиотеки не знаю. Хороших платных - тоже не знаю (в прошлой конторе работали с венграми HCC - тоже есть нарекания, но теперь ещё и за деньги; поддержка не очень помогает).

Если не поможет добавление буферов (и запись данных не по одному байту!) - открывается большой простор для творчества и костылестроения. Можно, например, свой драйвер FAT сделать, который будет писать в заранее подготовленный файл - количество записей уменьшится вдвое, не нужно будет обновлять запись FAT.

Ещё говорят, что usb-драйвер/библиотека/протокол (вся эта программная реализация usb) "съедает" много времени у ядра (и ресурсоёмкая), поэтому рекомендуют ставить самый высокий приоритет usb-прерыванию (0 или 1) соотвествующей функцией при инициализации.

Нет, после всех предварительных действий там просто перекладывание данных из памяти в регистры USB.
Правда, действительно, хост неадекватно себя ведёт, если приоритет прерывания достаточно низкий. Кто виноват, понять не удалось.

При использовании usb из-под куба тут на форумах где-то говорили, что эта rtx автоматом подключается в код без ведома программиста (это нужно для работы самого usb и всего с ним связанного, именно при применении куба).

Не читайте советских газет!
Куб, конечно, много чего "без ведома" творит, но не настолько же.

Кстати, куб в принципе не может работать под ОС (точнее, корректно обрабатывать обращения к одной и той же периферии из нескольких потоков).
Хотя может уже и поправили это безобразие:
stm32f1xx_hal_def.h

Код

#if (USE_RTOS == 1)
  #error " USE_RTOS should be 0 in the current HAL release "
#else

[Harvester]

Не читайте советских газет!
Куб, конечно, много чего "без ведома" творит, но не настолько же.

Газеты, может действительно не стоит читать, а вот то, что при использовании USB-библиотеки от ST подключается RTX - это факт.