Поменять порядок следования переменных EEPROM Опции

[SasaVitebsk]

Попробовал пару способов - не пошло. Хотелось бы поменять порядок следования переменных в EEPROM. Для этого требуется что-то типа прототипа переменной объявить. Как - не знаю. Размещать вручную все переменные - нехочу.

Описываю задачу.

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

.......

uint8_t __eeprom Rollint[] = {
0xDA, 0x54, 0x00, 0x00, 0x01, 0x08, 0x07, 0x01, 0x00, 0x0E, 0x00, 0x00, 0x00, 0x23, 0x33, 0x20, //
0xCF, 0xF0, 0xE8, 0xE2, 0xE5, 0xF2, 0x20, 0xEC, 0xE8, 0xF0, 0x20, 0xEF, 0xE0, 0xED, 0xED, 0xEE, //
0x21, 0x21, 0x21, 0x00, 0xDA, 0x45, 0x07, 0x07 //
};

uint32_t __eeprom eAdrProgEnd = sizeof(Rollint);

Так как объявлено сейчас - работает, но дело в том что этот массив может переписываться в процессе работы. По этому его надо разместить в конце EEPROM, а переменную eAdrProgEnd разместить где-нибудь перед ним. Если я механически переношу её вверх - выскакивает ошибка (оно и понятно - необъявлен Rollint). Пытался адрес закрепить типа @1, тоже ошибка, но уже линковщика.

Подскажите как это сделать правильно.

[zltigo]

Что-то порочное в самой постановке задачи.

0) В общем случае никто не гарантирует линковки в порядке упоминания переменных
1) Если массив постоянного размера, то зачем сдалась переменая - используйте прямо sizeof()
2) Если массив переменного размера и будет на ходу меняться, то какая разница, где находится
переменная - она ведь тоже будет меняться.
3) Если массив хрен знает какого размера (типа сколько влезет), то так программы вообще писать не стоит :-( - указывайте явно максимальный размер и явно инициализируйте начальный - все равно текущий придется инициализировать, так зачем с начальным извращаться?
4) ?

[SasaVitebsk]

Что-то порочное в самой постановке задачи.

0) В общем случае никто не гарантирует линковки в порядке упоминания переменных
1) Если массив постоянного размера, то зачем сдалась переменая - используйте прямо sizeof()
2) Если массив переменного размера и будет на ходу меняться, то какая разница, где находится
переменная - она ведь тоже будет меняться.
3) Если массив хрен знает какого размера (типа сколько влезет), то так программы вообще писать не стоит :-( - указывайте явно максимальный размер и явно инициализируйте начальный - все равно текущий придется инициализировать, так зачем с начальным извращаться?
4) ?

Скажу честно, я как то не надеялся на обсуждение идеи. Идею я привык оценивать сам. Причём привык очень давно. Бывает, и даже часто что я её меняю. Иногда по ходу проекта. Некоторые проекты переделывал по 4 раза. Причём без внешнего вмешательства. Так сказать элеменная база меняется, мы меняемся, взгляды меняются и т.д.

Но если Вам интересно, то выглядит так. Массив этот простирается (может простиратся) за пределы EEPROM во внешние EEPROM. По-скольку у меня m2560, а во внутреннем EEPROMе занято очень немного места, то я не считаю правильным выкидывать свободное место во внутреннем. Переменная eAdrProgEnd показывает ТЕКУЩИЙ занятый объём. При трансляции он совпадает с объёмом занятом в EEPROM. В процессе работы это значение может быть больше свободного места. Тогда п/п берущая значение будет добирать его с внешних источников.

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

Кстати посмотрел MAP файл (несколько насторожил и озадачил Ваш топик) переменные в EEPROM размещены в порядке их объявления.

[zltigo]

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

Вариант 4 будет правильным. Указываете насколько простирается максимальный размер и первоначальный размер ручками а не sizeof() :-( неявно инициализированного массива.
Если "хочется" решить задачу не думая о правильности ее постановки, то заводите две переменные - одну где-то "после", вторую (обнуленную) гарантированно "до". При первом запуске инициализируете "до" первой и все - можете накрывать неиспользуемую неконтролируемо растущим массивом.
Несколько более прилично - в отдельный сегмент массив выделить и попросить линкер гарантированно его конце его размещать.

Кстати посмотрел MAP файл (несколько насторожил и озадачил Ваш топик) переменные в EEPROM размещены в порядке их объявления.

А Вы не в map смотрите "как получилось", а в документ, где написано, что "так будет всегда".
А "всегда будет", если структуру-массив-union сделаете - для других случаев гарантий не предусмотрено.

[SasaVitebsk]

Вариант 4 будет правильным. Указываете насколько простирается максимальный размер и первоначальный размер ручками а не sizeof() :-( неявно инициализированного массива.

Массив явно инициализирован, но ниже по тексту. Конечно ручками не хотелось бы. Не то чтобы я белоручка ....

Если "хочется" решить задачу не думая о правильности ее постановки, то заводите две переменные - одну где-то "после", вторую (обнуленную) гарантированно "до". При первом запуске инициализируете "до" первой и все - можете накрывать неиспользуемую неконтролируемо растущим массивом.
Несколько более прилично - в отдельный сегмент массив выделить и попросить линкер гарантированно его конце его размещать.

Что значит "Если "хочется" решить задачу не думая о правильности ее постановки". В чём неправильность постановки??? С удовольствием выслушаю.

Возможно я не совсем внятно объяснил задачу. Разжую.

1) Выпускается законченный блок имеющий интерфейс rs485.
2) Блок имеет ряд характеристик (в том числе мастер/слэйв) значительно меняющими его работу.
3) С пом. спец программы блок работает в любом месте с любыми характеристиками. (Признак первого включения пока мне не требовался)
4) В блоке имеется память EEPROM и некоторые другие переферийные узлы. Всё это определяется на этапе инициализации оборудования динамически. В том числе объём внешней памяти. Перепрошивать прогу не надо.
5) Часть EEPROM занято данными на момент компиляции. Причём эти данные могут менятся в процессе производства (не регулярно. например раз в пол года).
6) Существует переменная указывающая объём занятый данными. В момент компиляции/производства она соответствует длине масива находящегося во внутреннем EEPROM.
7) Поскольку компилятор видит массив, то хотелось бы указать ему автоматически расчитывать значение занятого места.

Что в данной постановке задачи неправильно?

Вижу много (естественно) обходных путей её решения. В то же время я думал существует прямой ответ на мой вопрос. Существуют ведь прототипы функций, может есть и предварительное объявление массива типа "forward". Или каким образом попросить линкер разместить сегмент в конце? Как привязать к адресам я знаю. xcl файл использую.

[zltigo]

Массив явно инициализирован, но ниже по тексту. Конечно ручками не хотелось бы. Не то чтобы я белоручка ....

Нет! Размер массива явно НЕ указан. Если размер массива явно указать, то придется явно указывать
и количество инициализированных байтов. Неудобно, но проблемы отпадут :-(

1) Выпускается законченный блок имеющий интерфейс rs485.

Ничего не имею против.

2) Блок имеет ряд характеристик (в том числе мастер/слэйв) значительно меняющими его работу.
3) С пом. спец программы блок работает в любом месте с любыми характеристиками. (Признак первого включения пока мне не требовался)
4) В блоке имеется память EEPROM и некоторые другие переферийные узлы. Всё это определяется на этапе инициализации оборудования динамически. В том числе объём внешней памяти. Перепрошивать прогу не надо.

Просто святое дело!

5) Часть EEPROM занято данными на момент компиляции. Причём эти данные могут менятся в процессе производства (не регулярно. например раз в пол года).
6) Существует переменная указывающая объём занятый данными. В момент компиляции/производства она соответствует длине масива находящегося во внутреннем EEPROM.
7) Поскольку компилятор видит массив, то хотелось бы указать ему автоматически расчитывать значение занятого места.

А вот тут уже становится все просто очень хреново. Вместо нормально описанной структуры данных блока используется неструктурированный безразмерный массив абстрактных байтов - верный путь к проблемам.

Что в данной постановке задачи неправильно?

См.выше.

Вижу много (естественно) обходных путей её решения.

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

может есть и предварительное объявление массива типа
"forward".

Существует, естественно, только массив нужно явно объявить :-)