Как можно инициализировать структуру в ЕЕПРОМ използуя полей (имена полей) внутри структуры?

Сегодня из форума я узнал как сделать инициализацию ЕЕПРОМа с фиксированного адреса:

__root __eeprom uint8_t zast1[11] @ 0x2A = {0xFF, 0x44, 0x33, 0x11, 0x88, 0xAA, 0x77, 0x22, 0x44, 0xEE};


Но не могу понять как инициализировать структуру в ЕЕПРОМ ползуя имена полей. Например:

typedef struct
{
uint8_t status; /* STATUS */
uint8_t ID; /* ID */
uint16_t VER; /* VER */
} header_t;

Как можно инициализировать например поле status, ID, VER индивидуально? Я не хочу тратит програмный памяти для установки данны, хочу поставить данны директно в ЕЕПРОМ (EEP file).

__root __eeprom header_t myEEPROM = {
status = 2,
ID = 14,
VER = 8
}; /* НЕ РАБОТАЕТ */

Конечно я могу установить ЕЕПРОМ не применяя полей структуры, но код будет хуже для поддержки.

Или = { 2, 14, 8 }
или myEEPROM.status=2; myEEPROM.ID=14; myEEPROM.VER=8

Я что-то не понимаю какая разница где расположена структура при её начальной инициализации.

мне кажется такого должно быть достаточно

можно так




P.S. пока инет тормозил уже ответили.

Большое Спасибо - ответ был на 100% что искал!

Можно считать тему для закрытой - нечего можно добавить

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

В С++, есть конструкторы для таких вещей.

Только С-99 инициализация с именами полей (и с индексами массивов int array[20] = { [10] = 5 }; ) - это операция времени компиляции, которая заносит значения в секцию инициализированных данных и "бесплатна" с точки зрения размера кода, а С++ - конструкторы - это операция времени выполнения и дополнительный код.
"А в остальном, прекрасная маркиза, всё хорошо, всё хо-ро-шо".

Там много чего есть. Я писал свой комментарий в том смысле, что если планируется потом этот код использовать и в С++ программах, то такой прием использовать нельзя. Ну или если этот код попадет в С++ программу и посыпятся ошибки компиляции, то чтобы было понятно, где их искать.

А конструктор не может на этапе компиляции проинлайниться? это во первых

Во вторых в ячейку он может и занесёт, но это справидливо только для eeprom. А если это структура в RAM, то числа сначала лягут во флэш, а потом скопируются в инициализационном коде в оперативку. Так что бесплатность условная.

Проинлайненый код - всё равно код, его размер не может быть даже равен размеру данных, которые он в себе несёт.
Код копирования образа .data во флеше присутствует один на все инициализаторы и делится на всех, практически можно пренебречь.
Итого для
имеем
т.е. расход 1 батйт флеша на 1 байт проинициализированных данных (+ одна N-тая от общего кода копирования всей секции одним махом из флеша в ОЗУ)
А в случае самого заинлайненого конструктора
итого шесть байт флеша на один байт проинициализированных данных.
Реальность может оказаться ещё хуже - даже проинлайненный конструктор ляжет в цепочку таких проинлайненных конструкторов в пределах единицы компиляции, но все вместе образуют подпрограмму, которая будет вызвана при запуске, а её адрес или её вызов будет помещён в соответствующую таблицу, которая ещё займёт место.
Например, так:


Даже если бы компилятор уоптимизировал эти записи, загрущив один раз указательную пару и записывая по ней - всё равно в пределе расход при программной инициализации 4 байта флеша на байт проинициализированных даных, а при переносе образа - 1:1.
В этом смысле можно сказать, что добавление одной проинициализированной "по С" переменной бесплатно по коду (код копирования уже присутствует), а добавление "по С++" кроме самих инициализаторов добавляет коды операций загрузки этих инициализаторов в регистры и команды выгрузки их на нужное место.
Прикиньте, что будет при инициализации таблично-заданного развесистого меню в стиле с конструкторами.

Ну да всё правильно говорите.
Я и не утверждал что на плюсах код будет меньше.