[Stas633 0]

14 hours ago, jcxz said:

А почему пытаетесь врукопашную заменить компоновщик? Для размещения переменных в памяти ещё в прошлом веке придумали компоновщики. И в IAR "ессно" оно есть.

Я бы с радостью! Но только, разве компоновщик умеет данные во внешней памяти размещать? (с которой обращение через слой spi/i2c)

16 hours ago, SII said:

Определить тип структуры в отдельном заголовке, причём явным образом указать для неё alignas (если используется Си++11 или старше; насчёт чистых сей не в курсе -- не использую в связи с бессмысленностью); тогда компилятор вольничать с выравниванием не будет.

Да, такой выход рассматривался. Но, как самый простой и крайний (прямолинейный - "бери больше, кидай дальше...").

Хочется же понять чем вызвано "поведение" компилятора и как этим "поведением" управлять? Действия компилятора скрытые (не очевидные), ни каких сообщений нет, а как итог - неработающий код. Да IAR честно предупреждает в "Development Guide": ".. A normal pointer can be implicitly converted to a pointer to  __packed , but the reverse conversion requires a cast....". Но "sizeof" - это ни разу не указатель. (

[jcxz 184]

50 минут назад, Stas633 сказал:

Я бы с радостью! Но только, разве компоновщик умеет данные во внешней памяти размещать? (с которой обращение через слой spi/i2c)

А в чём проблема? Компоновщику без разницы где находится память.

[Stas633 0]

1 hour ago, jcxz said:

А в чём проблема? Компоновщику без разницы где находится память.

Про "IAR XLINK Linker" речь идет?

[jcxz 184]

36 минут назад, Stas633 сказал:

Про "IAR XLINK Linker" речь идет?

Любой. В том числе IAR.

Кроме того - структуру какой-либо памяти можно описывать посредством си-шного struct.

Вобщем можно и так и так - как удобнее, но не руками.

[SII 0]

10 hours ago, Stas633 said:

Я бы с радостью! Но только, разве компоновщик умеет данные во внешней памяти размещать? (с которой обращение через слой spi/i2c)

Создать образ программы, рассчитанный на резмещение во внешней памяти, -- да, умеет (как сказано, ему всё равно, какие адреса присваивать). Обеспечить запись/загрузку -- нет, естественно. Но в Вашем случае внешняя память и не годится, подозреваю, ибо она (память) не может прямо адресоваться процом (это не SDRAM и не какая-нибудь там NANDFlash, подключаемая к контроллеру памяти и поэтому адресуемая обычным образом), а соответственно, прямое исполнение кода/выборка данных из неё невозможна.

10 hours ago, Stas633 said:

Да IAR честно предупреждает в "Development Guide": ".. A normal pointer can be implicitly converted to a pointer to  __packed , but the reverse conversion requires a cast....". Но "sizeof" - это ни разу не указатель

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

[Сергей Борщ 119]

18 минут назад, SII сказал:

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

Никуда оно не уплывет. Есть выравнивание по-умолчанию, есть принудительное. Предполагаю, что в каком-то из заголовочных файлов есть "незакрытая" #pragma pack и выравнивание/упаковка структур в других файлах зависит от того, был ли включен этот заголовочный файл перед другими в тот или иной исходник. Не был включен - будет по-умолчанию, был включен - будет принудительное в соответствии с указанной #pragma pack

[k155la3 26]

12 hours ago, Stas633 said:

Я бы с радостью! Но только, разве компоновщик умеет данные во внешней памяти размещать? (с которой обращение через слой spi/i2c)

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

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

При старте эта таблица-индекс через интерфейс-драйвер spi-i2c-etc копируется в RAM контроллера. итд.

On 7/16/2020 at 4:05 PM, Stas633 said:

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

#define BEGIN_ROM 		0
#define PRIMARYDATA_ROM	BEGIN_ROM + 10
#define SECONDDATA_ROM	PRIMARYDATA_ROM+sizeof(struct MY_STRUCT)
  ....

Все прекрасно работало, пока . . . .

пока размер вложенности макроса не превысит возможный предел для компилятора. По крайней мере для IAR он был (возможно и есть, 256)

ps при этом никаких err-warn не выдается. 

[jcxz 184]

37 минут назад, k155la3 сказал:

пока размер вложенности макроса не превысит возможный предел для компилятора. По крайней мере для IAR он был (возможно и есть, 256)

А откуда Вы узнали его значение? Есть ссыль?

[k155la3 26]

2 hours ago, jcxz said:

А откуда Вы узнали его значение? Есть ссыль?

из собственного опыта. IAR/MSP430 6.40.1 - на это не проверял, а в более старой версии 5.xx.xx было. Возможно это и в других компиляторах есть, тк у вложенности должен же быть [разумный-логичный] предел. Похоже, если макрос раскрывается в строку более 256 длиной - происходит этот трабл (ограничение или по уровням вложения или на длину этой строки). 

#define BASE  0x100

#define ADDR_1     (BASE +1 )

#define ADDR_2     ( ADDR_1 +1 )

. . . .

#define ADDR_500     ( ADDR_499 +1 )

даже #define ADDR_2  раскрывается в 0x100 + (0x100 + 1) + 1, дальше снежный ком. Можно представить, что там будет на ADDR_500 :)

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

[Stas633 0]

On 7/17/2020 at 7:50 PM, Сергей Борщ said:

Никуда оно не уплывет. Есть выравнивание по-умолчанию, есть принудительное. Предполагаю, что в каком-то из заголовочных файлов есть "незакрытая" #pragma pack и выравнивание/упаковка структур в других файлах зависит от того, был ли включен этот заголовочный файл перед другими в тот или иной исходник. Не был включен - будет по-умолчанию, был включен - будет принудительное в соответствии с указанной #pragma pack

Спасибо, Сергей! "Заставили" проверить!

Проект большой, "много-авторский" (4+), поэтому и не искал здесь... (" ...в каком-то из заголовочных файлов есть "незакрытая" #pragma pack...).

Нашел, исправил (в ОДНОМ месте на 11Мб исходников, в строках подсчитать не возьмусь). Все норм. Вопрос снят! ))

On 7/17/2020 at 9:19 PM, k155la3 said:

...

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

..

Да, именно такой подход и использован. Т.е. формируется что-то типа FAT для внешнего хранилища (FLASH, EEPROM..), где в качестве параметров  в том числе и  размеры структур.

 

On 7/17/2020 at 9:19 PM, k155la3 said:

пока размер вложенности макроса не превысит возможный предел для компилятора. По крайней мере для IAR он был (возможно и есть, 256)

Не встречался с таким.

[k155la3 26]

9 hours ago, Stas633 said:

. . . Проект большой, "много-авторский" (4+), поэтому и не искал здесь... (" ...в каком-то из заголовочных файлов есть "незакрытая" #pragma pack...).

Нашел, исправил (в ОДНОМ месте . . . .

Ну, компиляторы Вам благодарны, облегчаете их работу, "ничего не прося взамен" :)  А если "четная ошибка" ?

Для себя сделал вывод, что использовать #pragma pac() - закладка граблей.

 

[Baser 5]

17.07.2020 в 21:19, k155la3 сказал:

пока размер вложенности макроса не превысит возможный предел для компилятора. По крайней мере для IAR он был (возможно и есть, 256)

Для C99 по стандарту ограничение 4095 символов.
По крайней мере, в ИАРе 7.50 для АРМ макрос вычисления номера бита из маски бита раскрывался в строку за 2048 символов, но все работало.
 

20.07.2020 в 20:00, k155la3 сказал:

Для себя сделал вывод, что использовать #pragma pac() - закладка граблей.

Предпочитаю применять
#pragma pack(1)
typedef ...
#pragma pack()
в обрамлении одиночной структуры или объединения.
При этом никаких побочных проблем не возникает.

[jcxz 184]

3 часа назад, Baser сказал:

Предпочитаю применять
#pragma pack(1)
typedef ...
#pragma pack()
в обрамлении одиночной структуры или объединения.
При этом никаких побочных проблем не возникает.

В IAR-е всё проще: __packed struct Zzzz {...};

И никаких проблем из-за склероза.