Все настройки представляют собой только одну cтруктуру, располагаемую в eeprom.
Внутри этой структуры есть переменные с глобальными настройками и массив структур с настройками профилей.
Задача в том, чтобы разместить структуры с настройками профилей с отступом друг от друга и отступом от настроек глобальных.
Нужно это для того, чтобы при увеличении количества настроек как глобальных, так и настроек профилей, они не затирали уже существующие данные.
Пишу на C, ARM SDT 2.51.
Кроме ручной вставки больших paddingo-в и последующего пересчета размеров оных при изменении структур, ничего не придумывается.
Полная версия этой страницы: Как "раскидать" структуры по EEPROM?
Цитата(Idle @ Jul 20 2007, 17:18) 
Все настройки представляют собой только одну cтруктуру, располагаемую в eeprom.
Внутри этой структуры есть переменные с глобальными настройками и массив структур с настройками профилей.
Задача в том, чтобы разместить структуры с настройками профилей с отступом друг от друга и отступом от настроек глобальных.
Нужно это для того, чтобы при увеличении количества настроек как глобальных, так и настроек профилей, они не затирали уже существующие данные.
Пишу на C, ARM SDT 2.51.
Кроме ручной вставки больших paddingo-в и последующего пересчета размеров оных при изменении структур, ничего не придумывается.
Внутри этой структуры есть переменные с глобальными настройками и массив структур с настройками профилей.
Задача в том, чтобы разместить структуры с настройками профилей с отступом друг от друга и отступом от настроек глобальных.
Нужно это для того, чтобы при увеличении количества настроек как глобальных, так и настроек профилей, они не затирали уже существующие данные.
Пишу на C, ARM SDT 2.51.
Кроме ручной вставки больших paddingo-в и последующего пересчета размеров оных при изменении структур, ничего не придумывается.
Выделить в отдельную секцию и в скрипте линкера прописать адреса для каждой структуры/группы структур.
Организация секций и скрипт линкера зависят от компилятора/линкера, который Вы используете.
Цитата(Idle @ Jul 20 2007, 18:18)
Все настройки представляют собой только одну cтруктуру, располагаемую в eeprom.
Внутри этой структуры есть переменные с глобальными настройками и массив структур с настройками профилей.
Задача в том, чтобы разместить структуры с настройками профилей с отступом друг от друга и отступом от настроек глобальных.
Нужно это для того, чтобы при увеличении количества настроек как глобальных, так и настроек профилей, они не затирали уже существующие данные.
Пишу на C, ARM SDT 2.51.
Кроме ручной вставки больших paddingo-в и последующего пересчета размеров оных при изменении структур, ничего не придумывается.
Внутри этой структуры есть переменные с глобальными настройками и массив структур с настройками профилей.
Задача в том, чтобы разместить структуры с настройками профилей с отступом друг от друга и отступом от настроек глобальных.
Нужно это для того, чтобы при увеличении количества настроек как глобальных, так и настроек профилей, они не затирали уже существующие данные.
Пишу на C, ARM SDT 2.51.
Кроме ручной вставки больших paddingo-в и последующего пересчета размеров оных при изменении структур, ничего не придумывается.
Отделить структуру global_data от profile_data и пользоваться указателями
Код
#define PROFILE_CNT 64
#define PROFILE_SIZE 128
typedef struct {
int g1;
//.....
uint8_t profiles[PROFILE_CNT * PROFILE_SIZE];
}global_data_t;
global_data_t global_data;
typedef struct {
int p1;
int p2;
//....
}profile_data_t;
profile_data_t* get_profile(unsigned num)
{
return (profile_data_t*)(global_data.profiles+num*PROFILE_SIZE);
}
#define PROFILE_SIZE 128
typedef struct {
int g1;
//.....
uint8_t profiles[PROFILE_CNT * PROFILE_SIZE];
}global_data_t;
global_data_t global_data;
typedef struct {
int p1;
int p2;
//....
}profile_data_t;
profile_data_t* get_profile(unsigned num)
{
return (profile_data_t*)(global_data.profiles+num*PROFILE_SIZE);
}
Цитата(Idle @ Jul 20 2007, 18:18)
Все настройки представляют собой только одну cтруктуру, располагаемую в eeprom.
Внутри этой структуры есть переменные с глобальными настройками и массив структур с настройками профилей.
Задача в том, чтобы разместить структуры с настройками профилей с отступом друг от друга и отступом от настроек глобальных.
Нужно это для того, чтобы при увеличении количества настроек как глобальных, так и настроек профилей, они не затирали уже существующие данные.
Пишу на C, ARM SDT 2.51.
Кроме ручной вставки больших paddingo-в и последующего пересчета размеров оных при изменении структур, ничего не придумывается.
Внутри этой структуры есть переменные с глобальными настройками и массив структур с настройками профилей.
Задача в том, чтобы разместить структуры с настройками профилей с отступом друг от друга и отступом от настроек глобальных.
Нужно это для того, чтобы при увеличении количества настроек как глобальных, так и настроек профилей, они не затирали уже существующие данные.
Пишу на C, ARM SDT 2.51.
Кроме ручной вставки больших paddingo-в и последующего пересчета размеров оных при изменении структур, ничего не придумывается.
Отделить структуру global_data от profile_data и пользоваться указателями
Код
#define PROFILE_CNT 64
#define PROFILE_SIZE 128
typedef struct {
int g1;
//.....
uint8_t profiles[PROFILE_CNT * PROFILE_SIZE];
}global_data_t;
global_data_t global_data;
typedef struct {
int p1;
int p2;
//....
}profile_data_t;
profile_data_t* get_profile(unsigned num)
{
return (profile_data_t*)(global_data.profiles+num*PROFILE_SIZE);
}
#define PROFILE_SIZE 128
typedef struct {
int g1;
//.....
uint8_t profiles[PROFILE_CNT * PROFILE_SIZE];
}global_data_t;
global_data_t global_data;
typedef struct {
int p1;
int p2;
//....
}profile_data_t;
profile_data_t* get_profile(unsigned num)
{
return (profile_data_t*)(global_data.profiles+num*PROFILE_SIZE);
}
Цитата(Idle @ Jul 20 2007, 17:18)
Кроме ручной вставки больших paddingo-в и последующего пересчета размеров оных при изменении структур, ничего не придумывается.
Думаю, можно попробовать использовать неименованные union внутри структуры, примерно так:Код
struct config_t
{
union
{
uint32_t dummy1[SIZE];
struct profile1_t
{
...........
} profile1;
};
union
{
uint32_t dummy2[SIZE];
struct profile2_t
{
...........
} profile2;
};
.........
};
#if sizeof(config_t) > зарезервированный размер
#error Какая-то из структур заняла больше, чем зарезервировано
#endif
{
union
{
uint32_t dummy1[SIZE];
struct profile1_t
{
...........
} profile1;
};
union
{
uint32_t dummy2[SIZE];
struct profile2_t
{
...........
} profile2;
};
.........
};
#if sizeof(config_t) > зарезервированный размер
#error Какая-то из структур заняла больше, чем зарезервировано
#endif
Идеальным вариантом, действительно, было бы использование "anonymous unions", стандартных для C++, но, к сожалению, для C этого нет ни в С89, ни в С99; мой компилятор также, увы, не поддерживает фичу в качестве расширения.
Т.е. простым изменением определения структур видимо не обойтись, и придется-таки перелопачивать все исходники и изменять(так или иначе) мульён строк. Эх, не подумали люди в свое время.
Хотя вариант с ручным паддингом все же остается.
Про секции и линковку посмотрю, смутно представляю как это, честно говоря.
Спасибо всем.
Т.е. простым изменением определения структур видимо не обойтись, и придется-таки перелопачивать все исходники и изменять(так или иначе) мульён строк. Эх, не подумали люди в свое время.
Хотя вариант с ручным паддингом все же остается.
Про секции и линковку посмотрю, смутно представляю как это, честно говоря.
Спасибо всем.
Цитата(Idle @ Jul 21 2007, 21:50)
мой компилятор также, увы, не поддерживает фичу в качестве расширения.
Ну так используйте поименованные. Это ничего принципиально не меняет в "идеальном" подходе.
Ну и линкером покомандовать вполе естественно, только плохо переносимо
При использовании именованных придется вставлять ".union_name." по всем исходникам, а так обошлось бы изменением определений, и остальное осталось как есть.
Цитата(Idle @ Jul 22 2007, 10:45)
придется вставлять ".union_name." по всем исходникам
А это уже работа редактора
. Нормальный редактор справляется с этим за несколько секунд, и имя из одной буквы необременительно для дальнейшего использования. А вообще резервировать места для непрогнозирумого развития как-то не хорошо - какие проблемы переместить данные при upgrade?
Переместить - не проблема. Но мне поставлена именно такая "боевая задача" . Раньше, при upgrad-е, все пользовательские настройки стирались и записывались дефолтные с измененной структурой(если изменялась), а сейчас вдруг выяснилось, что это неприемлемо. Сижу вот, сравниваю разные версии: где что изменилось - переписываю, новые добиваю дефолтные. Людям бы в конце структур новые члены добалять - нет, лепят в середине. Оставлю "снизу" свободное место, напишу крупными буквами, что new members в конец only и успокоюсь . Такие вот дела.
. Раньше, при upgrad-е, все пользовательские настройки стирались и записывались дефолтные с измененной структурой(если изменялась), а сейчас вдруг выяснилось, что это неприемлемо. Сижу вот, сравниваю разные версии: где что изменилось - переписываю, новые добиваю дефолтные. Людям бы в конце структур новые члены добалять - нет, лепят в середине. Оставлю "снизу" свободное место, напишу крупными буквами, что new members в конец only и успокоюсь . Такие вот дела.
Цитата(Idle @ Jul 22 2007, 12:10)
Переместить - не проблема. Но мне поставлена именно такая "боевая задача" . Раньше, при upgrad-е, все пользовательские настройки стирались и записывались дефолтные с измененной структурой(если изменялась), а сейчас вдруг выяснилось, что это неприемлемо.
Почему бы вам не прописывать в структуру одним из полей ее версию и после апгрейда при старте программы при необходимости конвертить настройки из старого формата в новый?
. Раньше, при upgrad-е, все пользовательские настройки стирались и записывались дефолтные с измененной структурой(если изменялась), а сейчас вдруг выяснилось, что это неприемлемо.
Такое поле есть. Конвертацией, которой раньше не было, я пока и занимаюсь. А поскольку пользователь может залить новую прошивку вместо той, что у него в наличии(т.е. сколь угодно старой), то надо для каждой старой версии (в зависимости от этого поля) сделать свой конвертер, т.е. сидеть-сравнивать: что было добавлено, что было удалено, что перешло из глобальных в локальные и т.д. Вот на будущее, чтобы не добавлять конвертацию, вопрос и был поднят.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.