Перейти к содержанию
    

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

У меня по всему коду разбросанны сообщения типа

printf ("LIB ID = %d\n", lib_id);

сообщения выводятся серийно на терминал.

 

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

Возникли вопросы по алгоритмике логирования данных

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

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

тогда что - держать глобальный указатель на файл?

3.Если файл закрыт - открыть с опцией "а+", добавить данные в файл, посмотреть флаг закрыть файл или нет.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

...

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

Через очередь -

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

 

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

1. писать мелкими файлами. например по 64кБ, как место кончилось -самый ранний стирать.

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Я исследовал быстродействие FatFS.

Результаты

Как видно время открытия и закрытия не такое уж критичное.

Поэтому у меня задача лога всегда открывает и закрывает файл после каждой инспекции очереди сообщений. Задача лога имеет самый низкий приоритет.

Очередь сообщений циклическая, особое внимание требует разруливание ситуаций переполнения очереди, поскольку это частая ошибка когда код начинает случайно логить в цикле.

А вот операция получения объема свободного места очень затратная по времени.

Так же не рекомендую создавать много мелких файлов, это увеличит время открытия и закрытия файлов.

Надо также думать сколько открытых файлов может одновременно поддерживать файловая система и сколько это занимает памяти.

Лучше не держать долго открытые файлы. Тогда лог будет иметь меньше влияния на остальной код который тоже может применять FS.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я исследовал быстродействие FatFS.

Результаты

Как видно время открытия и закрытия не такое уж критичное.

Поэтому у меня задача лога всегда открывает и закрывает файл после каждой инспекции очереди сообщений. Задача лога имеет самый низкий приоритет.

Очередь сообщений циклическая, особое внимание требует разруливание ситуаций переполнения очереди, поскольку это частая ошибка когда код начинает случайно логить в цикле.

А вот операция получения объема свободного места очень затратная по времени.

Так же не рекомендую создавать много мелких файлов, это увеличит время открытия и закрытия файлов.

Надо также думать сколько открытых файлов может одновременно поддерживать файловая система и сколько это занимает памяти.

Лучше не держать долго открытые файлы. Тогда лог будет иметь меньше влияния на остальной код который тоже может применять FS.

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

Изменено пользователем Jenya7

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Что, 255 байт хватит всем?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Если у вас суперцикл - разницы нет.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что, 255 байт хватит всем?

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

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

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

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

Изменено пользователем Jenya7

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня по всему коду разбросанны сообщения типа

printf ("LIB ID = %d\n", lib_id);

. . .

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

. . .

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

Rem:

ф-ия printf довольно "массивная" из-за своей универсальности. Соотв-но время на ее работу немалое.

Вам возможно имеет смысл пересмотреть структуру вывода на терминал и логгирования

с точки зрения "событийности".

При возникновении события вместо "балета" с формированием строки через printf и выводом ее на USART

фиксировать данные по этому событию в бинарной форме { Timestamp, CodeEventId , DataEvent }.

При этом все пишется в очередь, из которой эти записи извлекаются и выводятся в лог (без переформатирования)

и на терминал (через парсер-конвертер с printf)

 

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

Их неудобно обрабатывать, они занимают больше места.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

Вы не поняли.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если у вас суперцикл - разницы нет.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Т.е. - естественно не сам IAR, а stdlib которую он использует.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Т.е. - естественно не сам IAR, а stdlib которую он использует.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...