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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не-а. Следующий шаг - это разобраться, зачем вообще копировать данные из 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 отсутствует!).

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

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

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

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


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

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

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


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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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