Чёртовы эмбеддеры

[ex0_planet]

Скажите, коллеги, и просто сочувствующие, а вот у вас такой код не вызывает подозрений?

uint8_t *buffer = malloc(...) size_t offset = 0 buf_append_float32(buffer, config->voltage, 1e3, &offset); buf_append_float32(buffer, config->current, 1e3, &offset); buf_append_float32(buffer, config->temperature, 1e2, &offset);

Нет? Точно нет? А должен вызывать

Comments

[nicka_startcev]

>а вот у вас такой код не вызывает подозрений?

вызывает и дофига

1. зачем маллок вместо обычной локальной переменной на стеке
1а. фри не забыли? во всех ветках? а эксепшены убрать не забыли?
2. почему массив, а не структура

3. таки да, степени десятки и двойки, таки да, имена типов - это же извращенный фиксед, ни разу не флоат - это сантицельсии и милливольты с миллиамперами

4. вообще, да, удивляет, насколько "обычные программисты" обожают СИ и ненавидят СГС.

[ex0_planet]

1,1а это си. ничего не забыли, это здесь просто чтобы типы были понятны

2. потому что это потом в уарт отправлять и не морочиться с memory layout.

3. что надо курить чтобы ЭТО назвать float?

4. по факту это почти сгс и есть :)

[nicka_startcev]

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

2. делаю что-то типа mk_pkt(void *buffer, u32_t size) или без сайз, потому что сайз уже заполнен в пакете, а этак мк_ считает црц и прочие штампы.

ну, лайаут в любом случае надо бы помнить на стороне ембеддед. и с несовпадением лайаута могут быть примерно те же косяки как и с потоком append_foo(&offset); append_bar(&offset);

3. про флоат - дааа...

4. угу. хотя, я обычно натягиваю весь диапазон на весь диапазон инт_хх, или прибиваю полусантивольты гвоздями. плавучку для физ.величин как-то в голову не приходит применять.

[ex0_planet]

2. как насчёт структур переменного размера? пачку строк например заслать. це ж жах!

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

4. полусантивольты - это жёстко. в int32 как правило помещается всё что надо при разумном выборе базы из ряда (кило/милли/микро). или, для эстетов, в fp24:8 опять же при разумном выборе.

[nicka_startcev]

2. пачка строк - да, но это редкость. у меня чаще бывали портянки по 1..512 байт итого из инт8..16..32/флоат32 полей с разными именами. (как пример - дюжина приемопередатчиков с усилителями и фазокорректорами, а также их питанием и термеметрией

[ex0_planet]

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

Чаще же бывает так, что "ой, вот здесь еще терморезистор читать надо". Но в конфиге нет места. Точнее, изменение в каком-нибудь базовом MSG_GET_CONFIG сломает всю задеплоенную базу, а об версионировании протокола никто не подумал. Поэтому если мы этот NTC прилепим в хвост какому-нибудь MSG_GET_BATTERY_LEVEL, то почти никто ничего не заметит....

[nicka_startcev]

еще, кстати, стОит подумать про аналоги "NaN" - когда датчик отсутствует или бредит. чтоб при опросе посредника сразу было видно, где именно лажа.

[bigmaxx]

"потому что это потом в уарт отправлять и не морочиться с memory layout"
Я в таком случае с помощью union объявлял одни и те же данные и как структуру, для удобства обработки, и как массив байтов, для отправки/приёма.

[ex0_planet]

В любом случае на одном из концов придётся лезть грязными лапами прямо в байты - раскладка структур в памяти (в части padding и alignment) не гарантирована и у компиляторов в общем случае может быть разное мнение насчёт этого. Не говоря уж о endianness.

[bigmaxx]

Согласен: я потом вспомнил, что делал так не для передачи по интерфейсу, а для записи в EEPROM, т.е. с гарантированным использованием данных той же системой. Для межсистемного интерфейса машинно-зависимая сериализация - зло.