Логирование данных в файл. Опции

[Jenya7]

У меня по всему коду разбросанны сообщения типа
printf ("LIB ID = %d\n", lib_id);
сообщения выводятся серийно на терминал.

Сейчас нужно некоторые сообщения логировать в файл на SD карте.
Возникли вопросы по алгоритмике логирования данных
1. Прежде всего проверить есть ли место на SD - вопрос как это сделать? и если нет места? очистить файл и начать писать сначала?
2. Если файл открыт - добавить данные в файл, посмотреть флаг закрыть файл или нет.(я не хочу часто дергать файл - открывать\закрывать)
тогда что - держать глобальный указатель на файл?
3.Если файл закрыт - открыть с опцией "а+", добавить данные в файл, посмотреть флаг закрыть файл или нет.
Как вообще сделать покрасивше?

[AlexandrY]

Как вообще сделать покрасивше?

Я исследовал быстродействие FatFS.
Результаты
Как видно время открытия и закрытия не такое уж критичное.
Поэтому у меня задача лога всегда открывает и закрывает файл после каждой инспекции очереди сообщений. Задача лога имеет самый низкий приоритет.
Очередь сообщений циклическая, особое внимание требует разруливание ситуаций переполнения очереди, поскольку это частая ошибка когда код начинает случайно логить в цикле.
А вот операция получения объема свободного места очень затратная по времени.
Так же не рекомендую создавать много мелких файлов, это увеличит время открытия и закрытия файлов.
Надо также думать сколько открытых файлов может одновременно поддерживать файловая система и сколько это занимает памяти.
Лучше не держать долго открытые файлы. Тогда лог будет иметь меньше влияния на остальной код который тоже может применять FS.

[Jenya7]

Я исследовал быстродействие FatFS.
Результаты
Как видно время открытия и закрытия не такое уж критичное.
Поэтому у меня задача лога всегда открывает и закрывает файл после каждой инспекции очереди сообщений. Задача лога имеет самый низкий приоритет.
Очередь сообщений циклическая, особое внимание требует разруливание ситуаций переполнения очереди, поскольку это частая ошибка когда код начинает случайно логить в цикле.
А вот операция получения объема свободного места очень затратная по времени.
Так же не рекомендую создавать много мелких файлов, это увеличит время открытия и закрытия файлов.
Надо также думать сколько открытых файлов может одновременно поддерживать файловая система и сколько это занимает памяти.
Лучше не держать долго открытые файлы. Тогда лог будет иметь меньше влияния на остальной код который тоже может применять FS.

так все таки с очередями лучше чем первый вариант? я не вижу существенной разницы. только в первый вариант нужно добавить семафор.

Сообщение отредактировал Jenya7 - Mar 20 2018, 10:50

[jcxz]

так все таки с очередями лучше чем первый вариант? я не вижу существенной разницы. только в первый вариант нужно добавить семафор.

Если у вас суперцикл - разницы нет.
Если многозадачная ОС - без понимания работы в многопоточном окружении можете писать только шлак.

[Jenya7]

Если у вас суперцикл - разницы нет.
Если многозадачная ОС - без понимания работы в многопоточном окружении можете писать только шлак.

у меня ОС с задачами. выделить одну задачу на забор пакетов из очереди и записи в файл? я SD не задушу потоком сообщений?

[jcxz]

у меня ОС с задачами. выделить одну задачу на забор пакетов из очереди и записи в файл?

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

какие? только не говорите sprintf

Нет.
Я говорил уже не раз на форуме: stdlib IAR-а (и многих других компиляторов) имеет внутреннюю функцию:
extern "C" int _Printf( void *(*)(void *, int), void *, const char *, va_list *);
Она не декларирована в IAR-овских хидерах, но все прочие декларированные вовне printf, sprintf, vsprintf и всё это семейство внутри вызывают именно её.
Она обладает максимальными возможностями из всего этого семейства printf*, включает всё.
Я у себя в проектах IAR использую только её. И никаких других sprintf() или чего-то ещё.

[Jenya7]

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

а я вот туплю - как инициализировать семафор. я пользовался уже готовыми semTake, semGive.

Нет.
Я говорил уже не раз на форуме: stdlib IAR-а (и многих других компиляторов) имеет внутреннюю функцию:
extern "C" int _Printf( void *(*)(void *, int), void *, const char *, va_list *);
Она не декларирована в IAR-овских хидерах, но все прочие декларированные вовне printf, sprintf, vsprintf и всё это семейство внутри вызывают именно её.
Она обладает максимальными возможностями из всего этого семейства printf*, включает всё.
Я у себя в проектах IAR использую только её. И никаких других sprintf() или чего-то ещё.

вы уж меня извините но тащить этого монстра в свой проект я не буду.

[jcxz]

а я вот туплю - как инициализировать семафор. я пользовался уже готовыми semTake, semGive.

Я не знаю как это делать в vxWork - не использовал её.
Но да - потокобезопасное добавление данных в очередь можно сделать на базе семафора. Это один из вариантов.
Другие варианты: а) критическая секция; б) интерфейс на базе аналога InterlockedCompareExchangePointer() + дин.память; в)...?

вы уж меня извините но тащить этого монстра в свой проект я не буду.

В смысле??
А это разве не Ваше?:

У меня по всему коду разбросанны сообщения типа
printf ("LIB ID = %d\n", lib_id);

Читайте внимательнее мои посты:
Любая printf*-функция внутри вызывает _Printf() (в IAR). Воспользуйтесь отладчиком чтобы убедиться.
Так что Вы затащили ещё большего "монстра" к себе