Доброго времени суток, коллеги.
Наблюдаю следующую вещь. В цикле идёт периодическая запись одного байта в файл. Данные пишутся без проблем. Но если поставить для отладки светодиод в этот цикл, то по осциллограмме получается следующее: несколько раз светодиод моргает с одинаковой задержкой, а один раз эта задержка в несколько раз увеличивается. Задержка получается именно в функции записи в файл (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

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

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

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

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

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

CrimsonPig, спасибо за ответ.
А вот если мне надо писать периодически большой объём данных, пришедших, скажем, от ацп и делать это как можно ближе к реальному времени... Как быть? Вот накопил я буфер с несколькими килобайтами данных и пока их пишу на флэшку, сама эта функция записи весь мой реал и "убьёт" (пол секунды - это много). Что делать? Ведь сам ацп заполняет буфер очень быстро, а запись в файл идёт очень медленно.

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

Ээээ... если у вас данные поступают со средней скоростью 5Мб\с а средняя скорость записи в файл 2Мб\с то выход один - писать данные в /dev/null

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

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


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

XWoo, а куб-то пот кайлами в RTX вертится? Никогда его не использовал, поэтому спрашиваю
Если нет - таймер. Флаг подняли - по таймеру моргнули, если в RTX - задача без стека с самым низким приоритетом, ждущая флага (события, wait_evt вроде)

CrimsonPig, понял вашу мысль. Спасибо. Идея с несколькими буферами у меня проскакивала... Это часто используют при работе с ЖК-дисплеями/индикаторами для уменьшения "моргания" при обновления экрана.

toweroff, я никогда не пользовался ни одну ОСРВ. Ну не было таких задач, чтоб пришлось бы применять ОС. И не только у меня одного. Знакомые также не юзали ОС (однако они говорят, что рано или поздно придётся). Время покажет...

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

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

Сообщение отредактировал XWoo - Oct 21 2015, 06:53

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

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

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


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


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

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

esaulenka, советских газет более читать не будем.

Буду несколько буферов вводить и т.п. Посмотрим...

В версии куба для f2 уже стало возможным работать из-под ОС (там поправили "это безобразие").

Файл stm32f2xx_hal_def.h

#if (USE_RTOS == 1)
/* Reserved for future use */
#else
...
...
...
#endif /* USE_RTOS */

Моя мысль состоит в том, что рассчитывать на что-то отдаленно напоминающее realtime performance (необязательно с микросекундными временами реакции) имея NAND flash со встроенным контроллером и FTL + неизвестно как работающий FAT + сверху USB + C runtime просто глупо. SD-карточка и тем более какой-нибудь ЮСБ - свисток имею полное право без спроса устроить паузу на сотню миллисекунд, и запортить весь erase block размером в несколько мегабайт, опционально покорежив всю файловую систему.
Хочется гарантий - надо искать решения, в спецификациях на которые эти гарантии пописаны. Да и сделать такую систему (железо + весь стек разноуровнего софта сверху весьма непросто).
Так что надо осетра урезать

Не-а, они просто грабли поглубже спрятали.
Если без RTOS у них взводится свой собственный флажок (см. макросы LOCK), то при наличии операционки даже он отсутствует.


PS если проект ещё на стадии обдумывания, я б взял SD-карточку вместо этого USB. Там заметно прозрачнее всё устроено (хотя, конечно же, таймауты никуда не денутся, в соседней теме человек страдает...).

Понятно. Благодарю за комментарии.

В кубе в примерах есть много примеров работы с периферией как без ОС, так и с ОС. Тот же самый вариант с usb (который я взял для примера) есть и на ОС. Работает вроде как говорят. Сам не проверял.

С sd-карточкой тут уже не получится (сказали, надо usb-флэху). Дедам удобнее коннектить флэшку то в комп, то в девайс. Так сказать, мобильность нужна.

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

Во-во. Я ж где-то вычитал такое недавно на форуме тут. Пролистал бегло и не придал значения. Только вчера-сегодня вспомнил уже в этой теме, что где-то кто-то когда-то говорил об этом.

Вопрос в том, зачем она там нужна? ЧТо там происходит сложного, что туда автоматом "всовывают" эту ОС?

Получается, что в любом кубе под stm32 при использовании hal-usb добавляется и кейл rtx?

Сообщение отредактировал XWoo - Oct 21 2015, 11:58

Взял куб (полугодовой давности, я его не обновляю за ненадобностью).
Выбрал STM32F107 (кроме линейки 32F1xx у меня ничего не скачено - тоже не надо).
Компилятор - кейл.

Включил USB HOST (в режиме mass storage).
Нажал кнопку "сгенерировать проект". Запустил кейл, скомпилировал (собралось сразу, честь и хвала!).
RTX'ом не пахнет (какие доказательства предоставлять?).

Заодно расскажите, как этот куб генерирует проекты и под кейл (якобы с RTX), и под IAR, и под GCC. Там везде RTX ? Или их супер-код сам собой адаптируется?

Как ни странно, а мне тоже интересна "автоматическая" надобность ОС в данной библиотеки... Зачем она там подключается? Какова необходимость в ней?
С другой стороны usb host работает ведь хорошо (везде и у всех!), если не считать моей проблемки с неодинаковой длительностью записи в файл.

Сообщение отредактировал XWoo - Oct 22 2015, 05:44