[tonyk_av 39]

6 hours ago, Intel4004 said:

Это конечно-же не так

Значит, вы не поняли сути.

6 hours ago, Intel4004 said:

Использование секции .ARM.__AT_address не требует ее определения в скаттер-файле.

Ага, только если ты не определил секцию, значит, это сделал кто-то другой и куда он её поместил- вопрос.

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

1 hour ago, dimka76 said:

Если кроме самой __PLC_params  в этой секции ничего не будет, то однозначно располагаться будет с самого начала секции.

Если  __PLC_params будет первой в списке переменных, размещаемой в секции, то она будет размещаться с самого начала. Остальные переменные будут размещаться за ней в порядке их появления в поле зрения линковщика.

11 minutes ago, artemkad said:

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

Это, повторю, плохая идея.

11 minutes ago, artemkad said:

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

Во-первых, порядок размещения устанавливает линковщик, а не среда программирования. И этот порядок описан в доках на линковщик.

Во-вторых, для однозначного размещения существую сегменты, внутри которых помещаются секции, которые тоже можно позиционировать внутри сегмента (терминология ld).

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

Не забывайте, что кроме флэша может быть ещё и память с батарейной поддержкой, в которой тоже могут размещаться переменные, конкретные адреса которых никому не интересны, но всем важно, что они попали в нужный диапазон адресов.

[dimka76 54]

On 7/19/2024 at 10:01 AM, tonyk_av said:

Если  __PLC_params будет первой в списке переменных, размещаемой в секции, то она будет размещаться с самого начала.

О каком списке идет речь ? Где этот список ? Кто его формирует ?

[artemkad 62]

57 минут назад, tonyk_av сказал:

Если  __PLC_params будет первой в списке переменных, размещаемой в секции, то она будет размещаться с самого начала.

Если есть, предположим, две переменные указанные для размещения в этой секции, но в разных объектных файлах, которая из них будет первой?

[dOb 10]

1 час назад, dimka76 сказал:

Где этот список ?

В порядке как описано в проекте. IMHO

[artemkad 62]

9 минут назад, dOb сказал:

В порядке как описано в проекте. IMHO

Как ни странно, но Keil передает линковщику объектные файлы в виде *.o, а потому к порядку описанному в проекте это отношения не имеет.

А вот IAR да, сам передает список и потому уже он устанавливает порядок линковки

[tonyk_av 39]

Судя по отсутствию реакции от Zuse, он, пройдя по указанным ссылкам, уже разобрался, как позиционировать данные и код в памяти. Может, последуете его примеру и прочитаете? Там ведь всё расписано, и с примерами. Что ещё нужно? Не понимаю.

[jcxz 220]

12 часов назад, artemkad сказал:

Кстати, забавно что базовые библиотеки описывающие доступ к железу которое обычно по фиксированным адресам к услугам линковщика тоже не прибегают.

"Базовые" - это какие?

Насколько помню - CCS ("Code Composer Studio" от TI) как раз прибегает. Фрагмент "Linker command file" для ARM- и DSP-ядер OMAP L-137, описывающий регистры периферии:

MEMORY
{
  ...
  PAGE 2: //!<peripheral memory
  MMR_INTCD (RWI):     o = 0x01800000  l = 0x0200
  MMR_PDC (RWI):       o = 0x01810000  l = 0x0200
  MMR_IDMA (RWI):      o = 0x01820000  l = 0x0200
  MMR_CACHE (RWI):     o = 0x01840000  l = 0x8400 //!<only DSP-accessable
  MMR_EDMA3CC (RWI):   o = 0x01C00000  l = 0x5000
  MMR_EDMA3TC (RWI):   o = 0x01C08000  l = 0x0800
  MMR_PSC0 (RWI):      o = 0x01C10000  l = 0x1000
  MMR_PLL (RWI):       o = 0x01C11000  l = 0x0200
  MMR_SYSCFG (RWI):    o = 0x01C14000  l = 0x0200
  MMR_TMR (RWI):       o = 0x01C20000  l = 0x2000
  MMR_I2C0 (RWI):      o = 0x01C22000  l = 0x1000
  MMR_RTC (RWI):       o = 0x01C23000  l = 0x1000
  MMR_PRU (RWI):       o = 0x01C37000  l = 0x1000
  MMR_SPI0 (RWI):      o = 0x01C41000  l = 0x1000
  MMR_UART0 (RWI):     o = 0x01C42000  l = 0x1000
  MMR_MCASP (RWI):     o = 0x01D00000  l = 0xC000
  MMR_UART1 (RWI):     o = 0x01D0C000  l = 0x1000
  MMR_UART2 (RWI):     o = 0x01D0D000  l = 0x1000
  MMR_USB0 (RWI):      o = 0x01E00000  l = 0x7000
  MMR_SPI1 (RWI):      o = 0x01E12000  l = 0x1000
  MMR_MPU1 (RWI):      o = 0x01E14000  l = 0x1000
  MMR_MPU2 (RWI):      o = 0x01E15000  l = 0x1000
  MMR_GPIO (RWI):      o = 0x01E26000  l = 0x1000
  MMR_PSC1 (RWI):      o = 0x01E27000  l = 0x1000
  MMR_I2C1 (RWI):      o = 0x01E28000  l = 0x1000
  MMR_EMIFB (RWI):     o = 0xB0000000  l = 0x8000
  MMR_INTCA (RWI):     o = 0xFFFEE000  l = 0x2000
}

//!Maps the shared memory and peripherals memory to the memory areas.
SECTIONS
{
  ...
  .mmrSyscfgRegs        > MMR_SYSCFG,  PAGE 2
  .mmrPsc0Regs          > MMR_PSC0,    PAGE 2
  .mmrPsc1Regs          > MMR_PSC1,    PAGE 2
  .mmrPllcRegs          > MMR_PLL,     PAGE 2
  .mmrPrussRegs         > MMR_PRU,     PAGE 2
  .mmrDintcRegs         > MMR_INTCD,   PAGE 2
  .mmrAintcRegs         > MMR_INTCA,   PAGE 2
  .mmrIdmaRegs          > MMR_IDMA,    PAGE 2
  .mmrEdma3ccRegs       > MMR_EDMA3CC, PAGE 2
  .mmrEdma3tcRegs       > MMR_EDMA3TC, PAGE 2
  .mmrGpioRegs          > MMR_GPIO,    PAGE 2
  .mmrTmrRegs           > MMR_TMR,     PAGE 2
  .mmrRtcRegs           > MMR_RTC,     PAGE 2
  .mmrMcaspRegs         > MMR_MCASP,   PAGE 2
  .mmrSpi0Regs          > MMR_SPI0,    PAGE 2
  .mmrSpi1Regs          > MMR_SPI1,    PAGE 2
  .mmrI2c0Regs          > MMR_I2C0,    PAGE 2
  .mmrI2c1Regs          > MMR_I2C1,    PAGE 2
  .mmrUart0Regs         > MMR_UART0,   PAGE 2
  .mmrUart1Regs         > MMR_UART1,   PAGE 2
  .mmrUart2Regs         > MMR_UART2,   PAGE 2
  .mmrUsb0Regs          > MMR_USB0,    PAGE 2
  .mmrMpu1Regs          > MMR_MPU1,    PAGE 2
  .mmrMpu2Regs          > MMR_MPU2,    PAGE 2
  .mmrEmifbRegs         > MMR_EMIFB,   PAGE 2
  .mmrCacheRegs         > MMR_CACHE,   PAGE 2  //!<only DSP-accessable
  .mmrPdcRegs           > MMR_PDC,     PAGE 2
}

Как видно - привязка каждого блока периферии к его базовому абсолютному адресу производится именно в командном файле компоновщика.

Распределение регистров внутри каждого из этих блоков - описывается си-структурой в .h-файле.

 

PS: Я бы не стал говорить за все инструменты в мире, основываясь на опыте только с одним....  

1 час назад, artemkad сказал:

Если есть, предположим, две переменные указанные для размещения в этой секции, но в разных объектных файлах, которая из них будет первой?

Как решит компоновщик в соответствии с действующими у него в данный момент правилами.

1 час назад, dOb сказал:

В порядке как описано в проекте. IMHO

Это не так. К тому же - плохой способ. Чаще всего компоновщики компонуют секции в порядке уменьшения их размера. Потому так - меньше вероятность проблем. Сами подумайте почему.

Например: Если компоновка идёт в два региона памяти размерами: 64КБ + 32КБ, и в программе есть множество переменных (общим размером ==20КБ), кроме которых также имеется массив размером ==50КБ. Подумайте - что будет если следовать вашему правилу?

В этом случае компоновка по уменьшению размера секций более безопасна.

[dimka76 54]

On 7/19/2024 at 12:50 AM, artemkad said:

Кстати, забавно что базовые библиотеки описывающие доступ к железу которое обычно по фиксированным адресам к услугам линковщика тоже не прибегают.

Потому что эти библиотеке в памяти никакие переменные не размещают, а просто обращаются к нужным ячейкам памяти

Если развернуть все эти библиотечные макросы, то получится так

*((volatile uint32_t*)0x4000001A) = 256437;

А тут в теме вопрос стоит именно о размещении некоторой переменной по некоторому адресу.

[Intel4004 1]

10 hours ago, tonyk_av said:

16 hours ago, Intel4004 said:

Это конечно-же не так

Значит, вы не поняли сути.

16 hours ago, Intel4004 said:

Использование секции .ARM.__AT_address не требует ее определения в скаттер-файле.

Ага, только если ты не определил секцию, значит, это сделал кто-то другой и куда он её поместил- вопрос.

Вам два раза сказали, что "Использование секции .ARM.__AT_address не требует ее определения в скаттер-файле.", но вы продолжаете талдычить свои фантазии.

А ведь казалось бы, открыл любой проект, добавил в любой исходник строчку

unsigned const int IWasMistaken __attribute__((section(".ARM.__AT_0x08080A00"))) = 123; 

, скомпилял, не трогая scatter, заглянул в map-файл и убедился, что переменная IWasMistaken лежит именно по адресу 0x08080A00. Делов на 5 минут. Но нет, некогда проверять, надо срочно нести бред в массы.

Изменено 19 июля пользователем Intel4004

[tonyk_av 39]

1 hour ago, Intel4004 said:

Вам два раза сказали, что "Использование секции .ARM.__AT_address не требует ее определения в скаттер-файле."

А я разве где-то настаивал, что требует? Читаем внимательно, что я говорил:

11 hours ago, tonyk_av said:

если ты не определил секцию, значит, это сделал кто-то другой

Никто ведь не запрещает линковщику самому создавать секции по умолчанию. Почитайте доки на линковщик, там должен быть описан этот механизм для секций типа __AT.

1 hour ago, Intel4004 said:

но вы продолжаете талдычить свои фантазии.

Какие фантазии, кому и что я талдычу? Воспользуйтесь рекомендацией:

8 hours ago, tonyk_av said:

Судя по отсутствию реакции от Zuse, он, пройдя по указанным ссылкам, уже разобрался, как позиционировать данные и код в памяти. Может, последуете его примеру и прочитаете? Там ведь всё расписано, и с примерами. Что ещё нужно? Не понимаю

 

Изменено 19 июля пользователем tonyk_av

[artemkad 62]

2 часа назад, tonyk_av сказал:

Никто ведь не запрещает линковщику самому создавать секции по умолчанию.

Нет там никаких секций.

Переменные указанные для размещения в какой-то секции маркируются в объектном файле, а потом линковщиком эти маркеры заменяются на реальные адреса в секции времени исполнения. А в данном случае речь об абсолютных адресах в линейном адресном  пространстве  ARM-а которые от перемещений объектного кода не меняются  и внимания линковщика не требуют.

11 часов назад, jcxz сказал:

Как решит компоновщик в соответствии с действующими у него в данный момент правилами.

Где конкретно указаны эти правила для тех двух пользовательских переменных?

[tonyk_av 39]

19 hours ago, artemkad said:

Нет там никаких секций.

Тогда читаем:

Quote

The name of the section is only significant if you are trying to match the section by name in a scatter file. Without overlays, the linker automatically assigns __at sections when you use the --autoat command-line option. This option is the default. If you are using overlays, then you cannot use --autoat to place __at sections.

Так что всё ожидаемо и логично.

Я Кейлом не пользуюсь уже лет 20, но удивляет, что те, кто, пользуются

On 7/17/2024 at 11:01 PM, artemkad said:

упрощают себе жизнь прямой адресацией из основного кода.

Документация у Кейла вполне вменяемая, есть примеры. Синтаксис компилятора повторяет gcc, синтаксис и структура файла конфигуратора линковщика проще, чем у ld.

Изменено 20 июля пользователем tonyk_av