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

[Jenya7]

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

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

[RobFPGA]

Приветствую!

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

Через очередь -
Пишете все логи в очередь сообщений, а в отдельном потоке выгребаете из нее и пишете туда куда надо и со всеми плюшками и шлю. наворотами

Удачи! Rob.

[HardEgor]

Сейчас нужно некоторые сообщения логировать в файл на SD карте.

1. писать мелкими файлами. например по 64кБ, как место кончилось -самый ранний стирать.
2. А если карту выдернут, или питание кончится, или перезагрузится контроллер? Если у вас FAT, то он очень не любит такие действия, придется карту нести на комп и восстанавливать таблицу.

[haker_fox]

1. Прежде всего проверить есть ли место на SD - вопрос как это сделать? и если нет места? очистить файл и начать писать сначала?

Проверить место. Если нет, стереть самый старый файл. Попутно об этом уведомить либо через терминал, либо в отдельный файл.

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

Как-то так. Но аккуратно с многопоточностью.

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

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

[Jenya7]

Если подвести итог вышесказанному получиться что то такое

Код

FILE *g_log_fp;
int g_log_file_size;

void LOG_LogMessage(char *file, char *message, int value, int close)
{
    int file_size = 0;
    
    char buff[256] = { '\0' };
    char sval[10];
    
    ItoA(value, sval);
    strcat(buff, message);
    strcat(buff, sval);

    if (g_log_fp == NULL)
    {
        g_log_fp = fopen(file, "a+");
        
        if (g_log_fp != NULL)
            fputs(buff, g_log_fp);
    }
    else
        fputs(buff, g_log_fp);
    
    fseek(g_log_fp, 0, SEEK_SET);
    fseek(g_log_fp, 0, SEEK_END);
    file_size = ftell(g_log_fp);
            
    if (close)
        fclose(g_log_fp);
    else
        fflush(g_log_fp);
    
    if (file_size >= MAX_LOG_FILE_SIZE)
    {
        //LOG_Clear() ???
        //go to the next file ???
    }    
}

или я что то упустил в логике?

или через очередь ?

Код

char log_buffer[1024];
MSG_Q_ID log_messages_Q;

void LOG_Init(void)
{
    log_messages_Q = msgQCreate(100, 1024, 0);
}

void LOG_SengQ(char *message, int value)
{
    int size = strlen(message) + 4; //4 - for value
    char sval[10];
    
    log_buffer[0] = '\0';
    
    ItoA(value, sval);
    strcat(log_buffer, message);
    strcat(log_buffer, sval);
    
    msgQSend(log_messages_Q, log_buffer, size, NO_WAIT, MSG_PRI_NORMAL);
}

и потом в отдельном потоке msgQReceive(log_messages_Q, log_buffer, 1024, NO_WAIT); ?

я не думаю что очередь дает какие то преимущества.

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

[AlexandrY]

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

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

[Jenya7]

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

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

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

[andrew_b]

Код

    char buff[256] = { '\0' };
     strcat(buff, message);
     strcat(buff, sval);

Что, 255 байт хватит всем?
Никогда не используйте функции, не контролирующие выход за границу буфера. Используйте strncat, уж если на то пошло. Или strlcat.

[jcxz]

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

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

[Jenya7]

Что, 255 байт хватит всем?
Никогда не используйте функции, не контролирующие выход за границу буфера. Используйте strncat, уж если на то пошло. Или strlcat.

IAR давал мне возможность

Код

int size = strlen(message);
char buff[size ] = { '\0' };

в vxWorks я такую возможность не нашел вот и извращаюсь. динамическую алокацию отвергаю по возможности.

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

[k155la3]

У меня по всему коду разбросанны сообщения типа
printf ("LIB ID = %d\n", lib_id);
. . .
Сейчас нужно некоторые сообщения логировать в файл на SD карте.
. . .
Как вообще сделать покрасивше?

Rem:
ф-ия printf довольно "массивная" из-за своей универсальности. Соотв-но время на ее работу немалое.
Вам возможно имеет смысл пересмотреть структуру вывода на терминал и логгирования
с точки зрения "событийности".
При возникновении события вместо "балета" с формированием строки через printf и выводом ее на USART
фиксировать данные по этому событию в бинарной форме { Timestamp, CodeEventId , DataEvent }.
При этом все пишется в очередь, из которой эти записи извлекаются и выводятся в лог (без переформатирования)
и на терминал (через парсер-конвертер с printf)

Неэффективно использовать в лог-массивах данные в не оптимальном "человеческом" формате.
Их неудобно обрабатывать, они занимают больше места.

[andrew_b]

IAR давла мне возможность

Код

int size = strlen(message);
char buff[size ] = { '\0' };

в vxWorks я такую возможность не нашел

Это C99 как минимум.

вот и извращаюсь. динамическую алокацию отвергаю по возможности.

Вы не поняли.
Если вы выделили под сообщение буфер определённого размера, то strncat не позволит выйти за границу буфера. Она просто обрежет сообщение по длине.

[Jenya7]

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

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

[jcxz]

Если вы выделили под сообщение буфер определённого размера, то strncat не позволит выйти за границу буфера. Она просто обрежет сообщение по длине.

IAR имеет более эффективные средства печати в буфер (в памяти) ограниченного размера, чем собирать его strncat() или чем то ещё.
Т.е. - естественно не сам IAR, а stdlib которую он использует.

[Jenya7]

IAR имеет более эффективные средства печати в буфер (в памяти) ограниченного размера, чем собирать его strncat() или чем то ещё.
Т.е. - естественно не сам IAR, а stdlib которую он использует.

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

[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). Воспользуйтесь отладчиком чтобы убедиться.
Так что Вы затащили ещё большего "монстра" к себе

[Jenya7]

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


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

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

нет. это - printf ("LIB ID = %d\n", lib_id); - в vxWork - там мне не важно, там у меня мощный камень и ОС. но в проектах на IAR я printf не использую.

[jcxz]

но в проектах на IAR я printf не использую.

И зря. У меня проект для motor-control с соответствующими требованиями к реалтаймовости (ШИМ == 20кГц). И _Printf() прекрасно в это время работает никак не мешая.
А Ваш суп из ItoA + пачка strcat - это те же яйца, только в профиль.

[haker_fox]

я не думаю что очередь дает какие то преимущества.

Эстетические) Процессы асинхронно просто вызывают некую функцию

CODE

pushMsgToLog(...)

, которая уже внутри помещает сообщение в очередь. Получается естественно.
Другая задача асинхронно читает очередь, и получив очередное сообщение, форматирует его, готовит к записи в соответствующий файл.

[RobFPGA]

Приветствую!

Эстетические) ...

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

Удачи! Rob.

[jcxz]

логровать например из прерываний или из других нехороших мест куда обычному printf вход заказан.

Заказан кем? Достаточный размер стека и... вуаля! - sprintf прекрасно работает и из ISR.

[RobFPGA]

Приветствую!

Заказан кем? Достаточный размер стека и... вуаля! - sprintf прекрасно работает и из ISR.

Вобще то printf и sprintf это немного разные пчелы - жужжат по разному.
И стек этот наверное прямо в мозгу программиста будет - чтобы инфу получал без IO функций.

Удачи! Rob.

[jcxz]

Вобще то printf и sprintf это немного разные пчелы - жужжат по разному.
И стек этот наверное прямо в мозгу программиста будет - чтобы инфу получал без IO функций.

Вы не поверите, но практически одинаковые! Так как внутри они почти сразу вызывают указанную мной _Printf().
Только одна в первом аргументе передаёт ей указатель на callback-функцию записи в ОЗУ, а другая - на callback-функцию записи в поток ввода/вывода.
У меня, например, среди прочего _Printf() пишет прямо в поток TCP-сокета (расчленяя вывод на лету на отдельные кадры без промежуточного буфера и поддерживая ретрансмиссию тоже без буфера).
Свои callback-функции для _Printf() невероятно расширяют её возможности. Всё ограничивается только фантазией программиста.
А уж тривиальный вывод в буфер ограниченного размера делается через _Printf() на раз.

[RobFPGA]

Приветствую!

Вы не поверите, но практически одинаковые! Так как внутри они почти сразу вызывают указанную мной _Printf().
Только одна в первом аргументе передаёт ей указатель на callback-функцию записи в ОЗУ, а другая - на callback-функцию записи в поток ввода/вывода.

Да неужели? поверю Вам на слово
Но если они для Вас так одинаковы - что мешает Вам использовать printf в прерывании?

У меня, например, среди прочего _Printf() пишет прямо в поток TCP-сокета (расчленяя вывод на лету на отдельные кадры без промежуточного буфера и поддерживая ретрансмиссию тоже без буфера).
Свои callback-функции для _Printf() невероятно расширяют её возможности. Всё ограничивается только фантазией программиста.
А уж тривиальный вывод в буфер ограниченного размера делается через _Printf() на раз.

То есть пока ACK для сегмента не получим из printf не уйдем ?
Да уж - фантазия программиста страшная штука - но моя только заставляла меня свои _Printf() писать падла

Удачи! Rob.

[jcxz]

Но если они для Вас так одинаковы - что мешает Вам использовать printf в прерывании?

Ничего. Если будет нужно - использую.

То есть пока ACK для сегмента не получим из printf не уйдем ?

Да с чего бы? Для каждого отправляемого TCP-сегмента _Printf() естественно вызывается отдельно. У меня весь сетевой стек построен построен на callback-ах: от самого низа (Ethernet-DMA) до верхних HTTP и пр. - всё в пределах одной задачи ОС.

моя только заставляла меня свои _Printf() писать падла

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

[RobFPGA]

Приветствую!

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

Так я ж и говорю - неуемная фантазия программиста ну и ADuC812 - страшная штука!

Успехов! Rob.

[haker_fox]

Заказан кем? Достаточный размер стека и... вуаля! - sprintf прекрасно работает и из ISR.

Опасаюсь, что sprintf может задержать прерывание на время парсинга. А так - бросил в очередь. И пусть отдельная задача неспеша всё пишет.

[AlexandrY]

Опасаюсь, что sprintf может задержать прерывание на время парсинга. А так - бросил в очередь. И пусть отдельная задача неспеша всё пишет.

Эт ж зависит от реализации. sprintf не боле чем имя, которое может быть переопределено.
В компиляторах даже обязывают проводить адаптацию нижнего уровня функций класса printf.
Так что объективно рассуждать о них под embedded не имеет смысла, там может быть что угодно.
В моих проектах printf применяется в прерываниях, поскольку выводит синхронно без циклов ожидания в канал RTT, профилирован и имеет известную глубину стека. Т.е. полностью детерминирован.

[jcxz]

Опасаюсь, что sprintf может задержать прерывание на время парсинга.

Любое действие программы задерживает процессор. Это неизбежность. 0-тактовых команд в ARM пока нету.
А насчёт того на сколько: так у прерываний приоритеты есть и менее приоритетные никак не должны задерживать более приоритетные.
Да и голова у написателя кода тоже должна наличествовать.
А так: у Cortex-M вообще есть такой режим работы, когда он только в прерываниях и работает, а выходя из прерываний сразу впадает в сон. В таком режиме никакого кода кроме кода выполняющегося в ISR просто нету.