[jcxz 184]

Не вижу увеличения size на размер страницы.

Да, там в комментарии надо читать как "Чтение len страниц", а не байт. Ну или на размер умножить.

 

Чем ваши [8], [6]... лучше моих * 8, * 9?

Наглядностью. Это у Вас сейчас там два элемента. А когда будет больше? Да ещё и вложенные? У меня будут просто вложенные структуры, а у Вас - сложные формулы для вычисления адресов.

Если скажем внутри вашей флешь вам нужно разместить скажем три разных сложных объекта такой структуры:

struct JournalTyp1 { //каждая запись журнала занимает 2 страницы флешь
  u8 head;
  u16p8 fifo[16];
};

и два таких:

struct JournalTyp2 { //каждая запись журнала занимает 1 страницу флешь
  struct Record {  //формат записи журнала 
    u8 typ;
    u8 sost;
    u8 data1[1000];
    u8 data1[1517];   
  };
  u8 head;
  u8 map;
  u8 flags;
  u8 fifo[16][(sizeof(Record) + PAGESIZE - 1) / PAGESIZE];
};

среди прочих объектов.

То у меня структура флешь будет выглядеть просто и наглядно:

struct DFLASH {
  JournalTyp1 journalAA;
  JournalTyp1 journalAB;
  JournalTyp2 journalBA;
  u8 firmware[80];
  u8 reserved1[100];
  JournalTyp1 journalAC;
  u8 someData1[10];
  JournalTyp2 journalBB;
  u8 someData2[11];
};

А как будет у Вас? Приведите Ваш вариант? :rolleyes:

 

Мои функции проще.

void SfmData_read(uint8_t *pbuf, uint32_t addr, uint32_t num);

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

[ViKo 1]

Мне раз формулы задать, сложностей не вижу. Объектов у меня два десятка. Пока в каждой странице не более одного объекта. Есть объекты на много страниц.

Зато потом, не напрягаясь, пользуюсь определенными адресами.

В конце концов, любую структуру можно привести к указателю на массив char.

Ваша идея, скажем, хитровата, но мне не приглянулась. Больше информации нужно держать в голове. Выше вы уже продемонстрировали, что надо иметь в виду. :rolleyes:

[jcxz 184]

Ваша идея, скажем, хитровата, но мне не приглянулась. Больше информации нужно держать в голове. Выше вы уже продемонстрировали, что надо иметь в виду. :rolleyes:

С моей идеей как раз в голове держать ничего не надо. Всё делает компилятор. А с вашей - всё считать и контролировать размеры вручную.

И "раз формулы задать" - это видимо Вы гений разработки, что сразу предусматриваете все хотелки заказчиков, которые появятся в течение жизни прибора, что потом и редактировать не надо. И сжимать-оптимизировать не надо. Ну не все такие гении: в реальной жизни карту размещения приходится править постоянно. А бывает что исходники пишутся сразу для линейки разных устройств, и карта такая собирается из множества кусков #if/#else/#end. Кстати - как Ваш метод совместим с условной компиляцией? B)

Вы и остальные переменные в программах тоже define-ами размещаете? Или всё-таки доверяете компоновщику? :biggrin:

[ViKo 1]

Да, я гений. Я умею задать дефайнами размеры, варианты. Слышали такое: #ifdef, #else, #endif?

Я сам себе заказчик, творю, что хочу. А если что-то предлагают, тоже делаю, если идет на пользу прибору.

А что было вам не описать структуру с нормальными размерами?

Повторю вопрос, как вы контролируете, что структура не вылезла за размеры памяти? Вот я знаю, сколько страниц в памяти, на столько и умножаю размер, не более.

[jcxz 184]

Повторю вопрос, как вы контролируете, что структура не вылезла за размеры памяти?

В смысле? Вам надо объяснить как sizeof(struct FLASH) умножить на размер страницы? :wacko:

И что значит "нормальные размеры"? Структура у меня описывается теми элементами, которыми идёт распределение памяти.

Если память распределяется байтами (в тех случаях, когда так и нужно), то каждый байт структуры == байту в памяти; если страницами - каждый байт структуры == странице; если секторами (стирания) - каждый байт структуры == сектору.

Эта структура задаёт не какую-то переменную в памяти, она задаёт ПОРЯДОК РАСПРЕДЕЛЕНИЯ ДАННОГО РЕСУРСА (СТРАНИЦ В НЕКОЕЙ ПАМЯТИ)!! Вы похоже этого никак понять не можете. Зациклились на каких-то переменных в памяти.... Причём они тут??? :wacko:

Точно так же например у меня структурой задаётся распределение пространства адресов на CAN-шине. Тоже никаких переменных данного типа при этом не создаётся.

[ViKo 1]

В смысле? Вам надо объяснить как sizeof(struct FLASH) умножить на размер страницы? :wacko:

Объясните, что написали здесь, это понятно, дайте ответ на вопрос. Где и когда вы сравниваете размер вашей структуры (в байтах, умноженных на размер страницы) и размер памяти? Кому вы доверяете эту процедуру, или просто забили, на авось?

Да что там понимать? Не понятно только, зачем? Вы не могли в своей структуре задать размеры объектов, кратных размеру страницы? Умножение вам в помощь.

[jcxz 184]

Да, я гений. Я умею задать дефайнами размеры, варианты. Слышали такое: #ifdef, #else, #endif?

Гений, знающий про ifdef, вот Вам пример из конкретного коммерческого проекта (ПО для линейки устройств). Покажите пожалуйста как вы сделаете распределение страниц FLASH в Вашем стиле?

А мы посмотрим - чей вариант нагляднее и читаемее.

//каждый байт структуры соответствует странице DFLASH
union DFLASH {
  struct {
    u8 nastr[8];
    u8 jrnDayEnergy[10];
    u8 jrnMonthEnergy[5];
    u8 jrnEventFwUpdate[2];
    u8 jrnEventSetPwd[2];
    u8 jrnEventAccessDeny[2];
    u8 jrnEventTamper[2];
    u8 jrnEventClearEnergy[2];
    u8 jrnProfilePower[700];
    u8 jrnProfileBillingData1[39];
    u8 jrnProfileBillingData2[73];
    #if FIRMWARE_TARGET == FIRMWARE_TARGET_S04 || FIRMWARE_TARGET == FIRMWARE_TARGET_S07
    u8 jrnProfile_phase_A[510];
    u8 jrnProfile_phase_B[510];
    u8 jrnProfile_phase_C[510];
    u8 jrnProfileBillingData1_A[36];
    u8 jrnProfileBillingData2_A[64];
    u8 jrnProfileBillingData1_B[36];
    u8 jrnProfileBillingData2_B[64];
    u8 jrnProfileBillingData1_C[36];
    u8 jrnProfileBillingData2_C[64];
    #ifdef PKE
    u8 jrnEvent_PKE[2002];                 //Журнал текущих данных ПКЭ
    u8 jrnEvent_PKE_PandP[34];             //Журнал провалов,прерываний напряжения и перенапряжений
    u8 jrnEvent_PKEStatistic[368];         //Общий статистический журнал событий ПКЭ
    u8 jrnEvent_PKE_PandP_statistic[124];  //Журнал статистики по провалам, прерываниям, перенапряжениям
    #endif  //PKE
    #endif
    u8 jrnEventCosem[45];
    u8 jrnEventMonitorRegister[45];
    u8 jrnEventMeterConfiguration[45];
    #if FIRMWARE_TARGET == FIRMWARE_TARGET_S07
    u8 jrn_change_transformation_coefficient[10];
    #endif
    u8 jrn_Events_not_erase[10];
    u8 unuse0[FIRM_BUF_SIZE];  //резерв для DFLASH::firmware
  };
  struct {
    u8 unuse1[DF_N_PAGES - FIRM_BUF_SIZE];
    u8 firmware[FIRM_BUF_SIZE];
  };
};

Раз уж в теории никак не доходит, то может хоть на реальном примере дойдёт :rolleyes:

 

Где и когда вы сравниваете размер вашей структуры (в байтах, умноженных на размер страницы) и размер памяти? Кому вы доверяете эту процедуру, или просто забили, на авось?

Я эту "процедуру" доверяю стандартному инструменту, называемому assert_static.

А Вы какому авосю доверяете? ;)

[ViKo 1]

Замените в моих

#define SFM_SET1 (SFM_SYSTEM_BASE + SFM_PAGESIZE * 8)

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

А мне и assert не нужен, я глазами вижу количество используемых страниц.

[jcxz 184]

Замените в моих

Ага, значит в кусты. :laughing:

 

А мне и assert не нужен, я глазами вижу количество используемых страниц.

Т.е. - доверяете Авосю? Авось пронесёт. Всё ясно с Вашими методами "программирования"... :laughing:

[ViKo 1]

В кусты, так в кусты. Собственно, всё уже выяснили.