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

[Jenya7]

Мне нужно логировать данные. Вот пишу универсальный логер. Натраиваю куда писать (SD, Flash, UART) и какие данные писать. Я планирую передавать указатель на переменную или структуру которые надо логировать. Но как быть дальше? Данные надо сериализовать (упаковать в массив) для передачи дальше. И тут я застрял.

Код

void LOG_Send(uint32_t storage, void *data, uint32_t size)
{
    char buf[size];  //size of data???
    uint32_t i = 0;
    while (data)
    {
        buf[i++] = (char *)(*data++);
    }
    
    switch (storage)
    {
        case SD:
          SD_Log("log.txt", buf);
        break;
        case FLASH:
          Flash_Log(log_addr, buf);
        break;
        case UART:
          UART_SendString(UART2, buf);
        break;
    }
}

В строке buf[i++] = (char *)(*data++); ругается на приведение типов.

[novikovfb]

В строке buf[i++] = (char *)(*data++); ругается на приведение типов.

data имеет тип void*, его инкрементировать нельзя (размер указываемой области не определен). Самое простое - скопировать data в обычный указатель на char и не мучиться.

[Jenya7]

data имеет тип void*, его инкрементировать нельзя (размер указываемой области не определен). Самое простое - скопировать data в обычный указатель на char и не мучиться.

понял. сделал так.

Код

    char buf[size]; //size of data???
    char *data_p = data;
    uint32_t i = 0;
    while (data)
    {
        buf[i++] = (*data_p++);
    }

кстати а если я логирую во флеш и хочу потом вытащить данные - их надо десириализовать? то есть надо где то хранить информацию о днных которые я логировал?

[haker_fox]

то есть надо где то хранить информацию о днных которые я логировал?

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

[Jenya7]

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

понял. спасибо. не все так просто. придется поломать голову.

[Эдди]

Лучше сериализовать данные, а не передавать их в бинарной форме. Как вариант — JSON использовать или просто строки "параметр = значение".
Иначе смена даже разрядности процессора может привести к куче геморроя.

[Jenya7]

Лучше сериализовать данные, а не передавать их в бинарной форме. Как вариант — JSON использовать или просто строки "параметр = значение".
Иначе смена даже разрядности процессора может привести к куче геморроя.

если это SD то да , есть такая возможность. но если это Flash - нужно писать побайтово. я хочу сделать что то универсальное.

Сообщение отредактировал Jenya7 - Jan 17 2017, 10:28

[Эдди]

Тогда в самом начале сохраняйте информацию о типе данных (фиксированном, т.е. не int, а, скажем, int32_t), конечности (big/little/mid), выравнивании (скажем, на 32-битной системе int16_t скорее всего будут с выравниванием по 4 лежать) и количестве данных.

[aiwa]

В строке buf[i++] = (char *)(*data++); ругается на приведение типов.

Вы приводите к указателю содержимое data, а не data.
Нужно так:
buf[i++] = *((char*)data)++;

Сообщение отредактировал aiwa - Jan 17 2017, 10:42

[Эдди]

Еще проще и быстрее по производительности было бы вызвать memcpy. Хотя, если содержимое data не меняется, то зачем вообще его куда-то копировать?

[aiwa]

Еще проще и быстрее по производительности было бы вызвать memcpy. Хотя, если содержимое data не меняется, то зачем вообще его куда-то копировать?

Или data передавать в функции в качестве аргумента.

[haker_fox]

Иначе смена даже разрядности процессора может привести к куче геморроя.

Да быть этого не может. Если вы их правильно положите, и правильно извлечёте. TCP/IP пакет - это бинарные данные, а гоняются между всеми возможными платформами.

[Jenya7]

Еще проще и быстрее по производительности было бы вызвать memcpy. Хотя, если содержимое data не меняется, то зачем вообще его куда-то копировать?

я заранее не знаю тип данных. это может быть int, float или struct. пользователь конфигурирует что и куда логировать. вобще это в основном показания датчиков или системные ошибки.

кстати да. memcpy (buf, data, sizeof (data)) вполне работает

Сообщение отредактировал Jenya7 - Jan 17 2017, 11:05

[Эдди]

TCP/IP пакет - это бинарные данные, а гоняются между всеми возможными платформами.

И постоянно вызываются функции вроде htoa и т.п.
Но TCP/IP — понятно, там потоки большие. А вот если данных немного, лучше не заморачиваться.

[Сергей Борщ]

Следующий шаг:

CODE

template<typename T>
void LOG_Send(uint32_t storage, T const & data)
{
     LOG_Send(storage, &data, sizeof(T));
}

Позволяет писать в каждой точке вызова LOG_send(storage, my_struct) вместо LOG_send(storage, &my_struct, sizeof(my_struct)) и связанных с этим ошибок.
Но противники плюсов будут привычно ныть об "увеличении объема кода и подъедании ограниченных ресурсов".

[Jenya7]

Следующий шаг:

Код

template<typename T>
void LOG_Send(uint32_t storage, T const & data)
{
     LOG_Send(storage, &data, sizeof(T));
}

Позволяет писать в каждой точке вызова LOG_send(storage, my_struct) вместо LOG_send(storage, &my_struct, sizeof(my_struct)) и связанных с этим ошибок.
Но противники плюсов будут привычно ныть об "увеличении объема кода и подъедании ограниченных ресурсов".

что то не хочется ради логера весь проект переписывать на С++.
подозреваю что компилятор выполнит те же самые танцы с бубном. просто мы их не увидим.

[esaulenka]

Следующий шаг:

Код

template<typename T>
void LOG_Send(uint32_t storage, T const & data)
{
     LOG_Send(storage, &data, sizeof(T));
}

Позволяет писать в каждой точке вызова LOG_send(storage, my_struct) вместо LOG_send(storage, &my_struct, sizeof(my_struct)) и связанных с этим ошибок.

Не-а. Следующий шаг - это разобраться, зачем вообще копировать данные из data в buf.

Но противники плюсов будут привычно ныть об "увеличении объема кода и подъедании ограниченных ресурсов".

Да пусть ноют. Какой смысл спорить с людьми, ни устриц не видели, ни Пастернака не читали?

скажем, на 32-битной системе int16_t скорее всего будут с выравниванием по 4 лежать

А можно примеры таких систем? Они ведь очень широко распространены, правда?

[Jenya7]

Не-а. Следующий шаг - это разобраться, зачем вообще копировать данные из data в buf.

ну я еще в планирую добавить в buf timestamp и название переменной. но главное - функции Flash_Log(log_addr, buf); UART_SendString(UART2, buf);принимают массив чаров. что вполне естественно.

[Эдди]

Да пусть ноют. Какой смысл спорить с людьми, ни устриц не видели, ни Пастернака не читали?

Если даже абстрагироваться от этого, то есть элементарная причина не использовать С++: зачем учить лишний ЯП, если С за глаза хватает? Вы бы еще на go каком-нибудь предложили код написать ☺

А можно примеры таких систем? Они ведь очень широко распространены, правда?

Элементарно. У меня была проблема с портированием старого клиент-серверного кода на 64-битную архитектуру с 32-битной: там мало того, что бинарная структура передавалась и в памяти она безо всякого явного выравнивания хранилась, так еще и нестрогие типы данных использовались. Вот во что это в итоге превратилось. Без #pragma pack(push, 4) данные паковались бы с учетом 64-битности (аналогично и со всеми int'ами и т.п. нестрогими типами), в итоге поля структуры совершенно не соответствовали бы описанным позициям.
Благо, обычно little-endian архитектура, а то пришлось бы еще байты туда-сюда распихивать (а ведь бывают процессоры, в которых little-endian отсутствует!).

Еще во всяких граф. и мат. пакетах для ускорения вычислений данные обычно даже в массивах выравнивают по машинному слову. В итоге тоже может веселуха получиться при переходе между архитектурами.

Поэтому если уж работать с бинарными данными, то строго фиксировать их положение.

[Jenya7]

кстати а как мне вычислить размер void *data? sizeof тут не прокатит.

[Сергей Борщ]

кстати а как мне вычислить размер void *data? sizeof тут не прокатит.

Почему не прокатит? Он вам честно выдаст размер указателя. Или я не понял, что именно вы хотели получить? Тогда компилятор вас тем более не поймет.

Элементарно. У меня была проблема с портированием старого клиент-серверного кода на 64-битную архитектуру с 32-битной

Мы рады за вас, но вы ответили не на тот вопрос, который вам задали.

[Jenya7]

Почему не прокатит? Он вам честно выдаст размер указателя. Или я не понял, что именно вы хотели получить? Тогда компилятор вас тем более не поймет.


Мы рады за вас, но вы ответили не на тот вопрос, который вам задали.

а если это указатель на структуру? мне же нужен размер структуры.

[Сергей Борщ]

Если даже абстрагироваться от этого, то есть элементарная причина не использовать С++: зачем учить лишний ЯП, если С за глаза хватает?

Чтобы упростить себе работу по написанию новых программ. Да, все то же самое можно написать и на голом Си, но после освоения плюсов писание на голых Сях напоминает закат Солнца вручную.

а если это указатель на структуру? мне же нужен размер структуры.

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

[Эдди]

Мы рады за вас, но вы ответили не на тот вопрос, который вам задали.

32-битных машин еще пруд пруди! И не загорами 128-битные. Вот тогда уж вообще веселуха начнется...
А еще есть микроконтроллеры, где архитектура бывает еще и 8- и 16-битной.
И если бинарный файл писать на 16-битном МК, а потом попытаться без должных усердий прочесть на 64-битной машине, получится черт-те что.
Если же у пользователя компьютер на MIPS, то еще больше веселуха получится! Жаль, что мипсы закопали, очень впечатляющая архитектура и вполне имела бы жизнь... Но нет — дурацкие армы стали продвигать.

кстати а как мне вычислить размер void *data? sizeof тут не прокатит.

Как я уже неоднократно говорил, сделать структуру

Код

#pragma pack ...
typedef struct{
    size_t reclen;  // длина одной записи
    size_t recN;    // количество записей
    size_t align;    // выравнивание по...
    void *data;     // сами данные
} adata;
#pragma pack ...

И передавать в свою функцию указатель на эту структуру. В этом случае можно смело писать всю бинарную структуру на носитель в неизменном виде — вы легко сможете определить, сколько там элементов и как они в памяти расположены.

[Jenya7]

Чтобы упростить себе работу по написанию новых программ. Да, все то же самое можно написать и на голом Си, но после освоения плюсов писание на голых Сях напоминает закат Солнца вручную.


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

так я почему передаю void *data. я хочу чтоб функция была генерик. чтоб работала с любыми данными. наверное единственное решение то что предлагает Эдди. на этапе конфигурации определять размер.

[Эдди]

на этапе конфигурации определять размер.

Именно так обычно и делают. Взять как пример тот же malloc: он выделяет подобную структуру, где хранит помимо данных пользователя информацию о длине одной единице и их количестве, чтобы потом можно было все это удалить или вызвать realloc.

[esaulenka]

Если даже абстрагироваться от этого, то есть элементарная причина не использовать С++: зачем учить лишний ЯП, если С за глаза хватает? Вы бы еще на go каком-нибудь предложили код написать ☺

Можно абстрагироваться и ничего не делать вообще совсем, только языком чесать.
(по большому секрету: BTA_lib можно и нужно писать на плюсах. Там даже подвижки к объектной модели есть).

Элементарно. У меня была проблема с портированием старого клиент-серверного кода на 64-битную архитектуру с 32-битной:

Это всё прекрасно. Баек "как сделать плохо" я и сам могу рассказать.
Только я задавал совсем другой вопрос.

[Jenya7]

сделал такую структуру.

Код

typedef struct LOG_PARAMS_S
{
    uint32_t ena;  //0-disable, 1-enable
    uint32_t timestamp;  //0-none, 1-time, 2-date+time
    uint32_t storage;  //sd, flash, uart
    uint32_t data_size;
    char header[32];
    void *data;  
}LOG_PARAMS;

extern LOG_PARAMS logParams[10];

а так я планирую конфигурировать логер.

Код

void COM_Log(uint32_t argc, char** args)
{
    //log idx ena storage timestamp header data
    uint32_t idx = atoi(args[1]);
    uint32_t enable = atoi(args[2]);
    uint32_t log_storage = atoi(args[3]);
    uint32_t time_stamp = atoi(args[4]);
    uint32_t size;
    uint32_t var_type;
      
    if (idx >= MAX_LOGS)
    {
        Parser_SendString(USART2,msg_invinp,print_out);
        return;
    }

    logParams[idx].ena = enable;
    logParams[idx].storage = log_storage;
    logParams[idx].timestamp = time_stamp;
    
    if(strlen(args[5]) > 32)
       size = 32;
    else
      size =  strlen(args[5]);
    
    memcpy (logParams[idx].header, args[5], size);
    
    void *var = SetVariable(args[6], &var_type);
    
    logParams[idx].data = (uint32_t *)var;  //pointer to data
}

Сообщение отредактировал Jenya7 - Jan 17 2017, 16:57

[Сергей Борщ]

32-битных машин еще пруд пруди! И не загорами 128-битные.

Замечательно. А теперь еще раз перечитайте исходный вопрос постарайтесь ответить на него:

скажем, на 32-битной системе int16_t скорее всего будут с выравниванием по 4 лежать

А можно примеры таких систем? Они ведь очень широко распространены, правда?

[Эдди]

BTA_lib можно и нужно писать на плюсах

У меня мозг императивный, он ООПщину не воспринимает никак.

Только я задавал совсем другой вопрос.

Выше я на него ответил. Очень много железа распространено с не то, что не 64-битной архитектурой (таких, пожалуй, до сих пор большинство), но даже не с little-endian (тех, правда, мало).

[Сергей Борщ]

так я почему передаю void *data. я хочу чтоб функция была генерик. чтоб работала с любыми данными.

Вы такую функцию и показали - она принимает указатель на void и размер. Теперь вам надо ей передавать размер каждый раз вручную. Как тремя строчками заставить это делать компилятор для любых типов данных - я показал. Но для этого требуется переходить на С++. Но вы примкнули к тем, кто хочет все делать на голом Си. Пожалуйста. Можете написать макрос

CODE

#define LOG_SEND(storage, data) LOG_Send(storage, &data, sizeof(data))

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

Выше я на него ответил.

Нет. Или давайте перефразируем: на какой вопрос вы ответили выше?

[jorikdima]

подозреваю что компилятор выполнит те же самые танцы с бубном. просто мы их не увидим.

В этом и прелесть!

[Jenya7]

Вы такую функцию и показали - она принимает указатель на void и размер. Теперь вам надо ей передавать размер каждый раз вручную. Как тремя строчками заставить это делать компилятор для любых типов данных - я показал. Но для этого требуется переходить на С++. Но вы примкнули к тем, кто хочет все делать на голом Си. Пожалуйста. Можете написать макрос

Код

#define LOG_SEND(storage, data) LOG_Send(storage, &data, sizeof(data))

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


Нет. Или давайте перефразируем: на какой вопрос вы ответили выше?

Сергей! Вы красиво разрулили и без плюсов!

[Jenya7]

В этом и прелесть!

я когда то думал что HAL прелесть. потом решил работать на уровне регистров. Мне нужен полный контроль и понимание происходящего.

вот если Сергей напишет туториал - программирование ембедед в плюсах тогда да.
Сам поизводитель SPL и примеры предоставляет в С. Если бы они то же самое продублировали в С++ не так боязно было бы пересесть на C++.


Сообщение отредактировал Jenya7 - Jan 18 2017, 07:05

[haker_fox]

потом решил работать на уровне регистров.

Вы же не используете регистры "пользовательском" коде? Я имею в виду, вы же не используете в коде логгера регистры? Т.е. HAL у вас всё равно есть.

Мне нужен полный контроль и понимание происходящего.

Обилие регистров как раз должно лишить вас этого

вот если Сергей напишет туториал - программирование ембедед в плюсах тогда да.

Да оно мало отличается от компьютера) Принцип тот-же.

Если бы они то же самое продублировали в С++

А я оборачиваю CMSIS, lpcopen, FatFS в Си++. Не боязно. Удобно!

не так боязно было бы пересесть на C++.

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

Например: в коде для LPC1768 выделяется динамически память. В проге для компа вы её можете выделить в первой строчке функции main(). В железяке такое может не пройти, если куча инициализируется не в startup-файле, а после. Вроде всё просто, а люди задают вопросы)

[Сергей Борщ]

вот если Сергей напишет туториал - программирование ембедед в плюсах тогда да.

"Чтение документации из интернета вслух - 100 евро в час". Нет никаких чернил для второго класса Си плюсов для контроллеров. Есть обычные плюсы и голова программиста.

[mdmitry]

....
Сам поизводитель SPL и примеры предоставляет в С. Если бы они то же самое продублировали в С++ не так боязно было бы пересесть на C++.

Посмотрите здесь как сделано у одного из соавторов scmRTOS.

[Jenya7]

Посмотрите здесь как сделано у одного из соавторов scmRTOS.

спасибо. выглядит интересно. попробую разобраться.

[zltigo]

А можно примеры таких систем? Они ведь очень широко распространены, правда?

Поскольку я НЕ ЗНАЮ ни одной платфомы, где это было бы не так, то мне очень интересно, существует ли вообще платформа, где данные пофиг, как выровнены. Хотя ответ я знаю у удручающей точностью - не существует - ограничения железа.

[Сергей Борщ]

Поскольку я НЕ ЗНАЮ ни одной платфомы, где это было бы не так,

Ну хоть одну назовите наконец. Во всех известных мне платформах (что 16-битных, что 32-х, что 64-х) 16-битные данные выравниваются на два байта.

[aiwa]

Если даже абстрагироваться от этого, то есть элементарная причина не использовать С++: зачем учить лишний ЯП, если С за глаза хватает? Вы бы еще на go каком-нибудь предложили код написать

Если абстрагироваться, то это - не изучение лишнего/нового языка, а расширение словарного запаса.