Приведение типа указателя на элемент структуры Опции

[ViKo]

Допустим, имеется структура из байтов. Хочу инициализировать сразу 2 байта 16-битовым числом, или сразу 4 байта 32-битовым числом. Привожу указатель к нужному типу.

Код

typedef struct {
  __IO uint8_t A;
  __IO uint8_t B;
  uint16_t RES;
} DEV_t;

  DEV_t Dev;
  DEV_t *pDev = &Dev;

  pDev->A = 0x55;
  pDev->B = 0xAA;
  (uint16_t)pDev->A = 0x3333;
  (uint32_t)pDev->A = 0x01234567;

Код работает. Но Keil выдает предупреждения:
source\Exercises.c(117): warning: #1441-D: nonstandard cast on lvalue
Есть ли способ написать так, чтобы Keil не возмущался?

[AHTOXA]

*(uint16_t*)&Dev.A = 0x55AA;

[ViKo]

*(uint16_t*)&Dev.A = 0x55AA;

Да, так работает без предупреждений.
И без специально созданного указателя.

[AHTOXA]

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

[ViKo]

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

Для того и вводятся резервные места, ну, как в stm32xxx.h

Код

typedef struct
{
  __IO uint32_t DR;         /*!< CRC Data register,             Address offset: 0x00 */
  __IO uint8_t  IDR;        /*!< CRC Independent data register, Address offset: 0x04 */
  uint8_t       RESERVED0;  /*!< Reserved, 0x05                                      */
  uint16_t      RESERVED1;  /*!< Reserved, 0x06                                      */
  __IO uint32_t CR;         /*!< CRC Control register,          Address offset: 0x08 */
} CRC_TypeDef;

По такой аналогии и создавал. Правильное заполнение структуры будет обеспечено, а обращение возможно по любому (невыровненному) адресу. Cortex-M3 же.

[_Артём_]

Правильное заполнение структуры будет обеспечено, а обращение возможно по любому (невыровненному) адресу. Cortex-M3 же.

А на каких архитектурах при таком обращении возникнут проблемы (и какие)?

[ViKo]

А на каких архитектурах при таком обращении возникнут проблемы (и какие)?

*(uint32_t *) &Dev.B = 0x02468ACE;
для ARM7. обращение по невыровненому адресу.

[toweroff]

*(uint32_t *) &Dev.B = 0x02468ACE;
для ARM7. обращение по невыровненому адресу.

то есть перед объявлением добавляем __packed?

[_Артём_]

*(uint32_t *) &Dev.B = 0x02468ACE;
для ARM7. обращение по невыровненому адресу.

И что будет ? HardFault?

[ViKo]

то есть перед объявлением добавляем __packed?

У меня Cortex-M3, ничего не добавляю, и так хорошо.

[_Артём_]

то есть перед объявлением добавляем __packed?

Без packed компилятор сам выравняет?

[ViKo]

И что будет ? HardFault?

А то!
http://www.google.by/webhp?rlz=1C1GGGE_ruB...745&bih=925

Добавлю. Мне не нужно "утрамбовать" структуру. Наоборот, я описываю в структуре регистры внешнего устройства, в частности, контроллера ЖКИ. С расположением регистров по конкретным адресам. Все, как в упомянутой stm32xxx.h. А обращаться хочу не только по байтам, но и целыми словами.

[MrYuran]

А на каких архитектурах при таком обращении возникнут проблемы (и какие)?

На многих, отличных от 8 бит.
Например, MSP430. По умолчанию выравнивание по границе слова.
Выровненный char займет 2 байта, старший байт 16р инициализатора вместо второго чара улетит в пустоту

я описываю в структуре регистры внешнего устройства, в частности, контроллера ЖКИ.

Вот в таком случае аттрибут упаковки строго обязателен.
Иначе такие чудеса могут начаться..
Пишешь байт в один регистр, а он улетает в соседний или через несколько

Конечно, не ваш конкретный случай, но все же

[ViKo]

Вот в таком случае аттрибут упаковки строго обязателен.
Иначе такие чудеса могут начаться..
Пишешь байт в один регистр, а он улетает в соседний или через несколько

Так заполняю же все адреса подряд! RESERVED вставляю во все дыры!

[MrYuran]

Так заполняю же все адреса подряд! RESERVED вставляю во все дыры!

А неважно.
Выровняет по границе машинного слова (16/32/64) - и все ваши RESERVED превратятся в дополнительные 16/32/64р "дыры"
Очень аккуратно нужно действовать, иначе наколоться можно очень неприятно.

[ViKo]

А неважно.
Выровняет по границе машинного слова (16/32/64) - и все ваши RESERVED превратятся в дополнительные 16/32/64р "дыры"

Не выравняет. Потому что имеется следующий код.

Код

typedef struct {
  __I uint8_t RCR;    //<! Revision Code Register,            0x00
  __I uint8_t DBSR;    //<! Dislpay Buffer Size Register,        0x01
  __I uint8_t CRR;    //<! Configuration Readback Register,        0x02
} ReadOnlyConf_t;    //<! Read-Only Configuration Registers

typedef struct {
  __IO uint8_t MCCR;    //<! Memory Clock Configuration Register,    0x04
  __IO uint8_t PCCR;    //<! Pixel Clock Configuration Register,    0x05
} ClockConf_t;        //<! Clock Configuration Registers
...

#define DPYCTRL_BASE    ((uint32_t)0x6C000000)    //<! Dysplay base address
#define S1DREGS_BASE    DPYCTRL_BASE        //<! S1D13706 registers base

#define READONLYCONF_BASE    S1DREGS_BASE
#define CLOCKCONF_BASE        S1DREGS_BASE + 0x04
#define LOOKUPTABLE_BASE    S1DREGS_BASE + 0x08
...
#define READONLYCONF    ((ReadOnlyConf_t *) READONLYCONF_BASE)
#define CLOCKCONF    ((ClockConf_t *) CLOCKCONF_BASE)
#define LOOKUPTABLE    ((LookUpTable_t *) LOKUPTABLE_BASE)
...

А дальше - обращения по указателям...

[_Pasha]

Для того и вводятся резервные места, ну, как в stm32xxx.h

Не надо брать пример с индуистского кода. Правильный ответ(причем, всегда)

Код

typedef struct
{
  __IO uint32_t DR;         /*!< CRC Data register,             Address offset: 0x00 */
  union
{
  __IO uint8_t  reg8bit;        /*!< CRC Independent data register, Address offset: 0x04 */
  uint32_t IDR_space;
} IDR;
  __IO uint32_t CR;         /*!< CRC Control register,          Address offset: 0x08 */
} CRC_TypeDef;

Почему у них идеологически не так? Патамушо эти хедеры не для того, чтобы ими пользоваться!

[_Артём_]

Патамушо эти хедеры не для того, чтобы ими пользоваться!

Интересно, а чем же пользоваться?
Самому хидеры на процы делать?

[_Pasha]

Интересно, а чем же пользоваться?
Самому хидеры на процы делать?

Я тут давеча психанул и наваял по означенному выше принципу. Ессно, только структуры, без всяких функций сомнительного сервиса. Но у проекта, который сейчас пилю, уже поезд ушел, тестинг откладывается.
Странно, но LPC такой ненависти не вызывают. Очень странно...
Вообще, я там сильно повыделывался - дал битовым полям осмысленные имена... там по-хорошему надо двуязычие, тоже на основе union{}- с сохранением мнемоники и с сохранением смысла... этот момент разрулю - будет тыщи три строк.
И вроде бы взять да и сделать базу в libreoffice base, чтоб генерило то,что надо... блин, лень забадала.

Сообщение отредактировал _Pasha - Oct 17 2012, 16:27

[AHTOXA]

А в каком случае может не сработать индуистский вариант? Я что-то с наскока не смог добиться, чтобы размер структуры

Код

typedef struct
{
  uint32_t DR;
  uint8_t  IDR;
  uint8_t  spacer;
  uint16_t  spacer2;
  uint32_t CR;
} CRCpeDef;

был не 12. Пробовал все мыслимые варианты -fpack-struct=1, 2, 4, 8, 16.

[toweroff]

Ух как у меня все это перекликается... и с volatile, и со структурами
Тоже бодаюсь. Чуть позже выложу, если позволите, в этой теме, ибо оооочень похоже

[ViKo]

Не надо брать пример с индуистского кода. Правильный ответ(причем, всегда)
...

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

Код

...
  __IO uint16_t BSRRL;    /*!< GPIO port bit set/reset low register,  Address offset: 0x18      */
  __IO uint16_t BSRRH;    /*!< GPIO port bit set/reset high register, Address offset: 0x1A      */
  // __IO uint32_t BSRR;        // GPIO port bit set/reset: 0xRRRRSSSS, Address offset: 0x18
...
} GPIO_TypeDef;

Причем, BSRRL отвечает за установку бита, а BSRRH - за сброс.
Но при пользовании объединениями в имени регистра появляется дополнительное обозначение, которого не хочу.
Поэтому приведение типа указателя для меня более приемлемо.

А насчет библиотеки - функциями не пользуюсь.
А насчет определения битов - #define меня устраивают.
Главное, чтобы код не разбухал.

[toweroff]

Итак, добавляю
есть две области в ARM968E-S
в первой висит 16-битный супресс USB, во второй - NOR Flash

Читается/пишется в первую область только по/из фиксированным адресам
Во вторую - и так, и с инкрементом

оптимизация компилятора в Time и O3

Шины. 1-я с супрессом - 16бит, 2-я - 32 бит

Что-то фигню наблюдаю

Первая область объявлена как

Код

#define        FX2_FIFO2            (*(volatile unsigned int *)(FX2_BASE_ADDR + (0x00UL<<2)))
#define        FX2_FIFO4            (*(volatile unsigned int *)(FX2_BASE_ADDR + (0x02UL<<2)))

вторая - также через volatile, но в своем диапазоне

Доступ к памяти осцилл показывает и, судя по тестам, точно как и надо

А вот данные - не пойми чего
Для пересылки и сокращения доступа к той и другой области памяти попробовал сделать union с тремя полями - U16, U16 и U32
Например, чтение из первой области - в две U16 подряд, потом из U32 - в другую область запись

Шаманство Не работает

[_Pasha]

Я тоже кинулся было править stm32f2xx.h, когда увидел, что не могу одной командой установить и сбросить биты в порту. Из-за[кусь]
Поэтому приведение типа указателя для меня более приемлемо.

Не пойму, кто заремил BSRR, милое дело ©

Код

Inline void pin_set_by_msk(const GPIO_typedef *port, const uint16_t msk, const bool state)
{
  port->BSRR = state?(msk):(msk<<16);
}

компиляется в минимум,- жаль, редко, когда в две-это при интенсивных операциях -инструкции

Сообщение отредактировал _Pasha - Oct 17 2012, 18:24

[ViKo]

Не пойму, кто заремил BSRR, милое дело ©

Я же и закомментировал. Сам приписал, сам убрал. Когда возникла дилемма - или писать всегда по 32 бита, или писать, когда надо, по 16-битов. В-общем, надо было иметь и ту, и другую возможность. А union ... уже говорил ... А *(uint32_t *) &GPIOB.BSRRL - то шо надо!

[AHTOXA]

Не пойму, кто заремил BSRR, милое дело ©

Дык, индусы, кто ж ещё Причём битовые маски оставили как для 32-битного BSRR. (Это для F2xx.)
Я всё же такого не стерпел, и переписал это определение.
_Pasha, так в каком случае индуистский подход с ручными отступами в структурах может привести к неправильному результату? Или здесь речь чисто об эстетике?

[toweroff]

Админы, я так понимаю, здесь свой колхоз
я это все отправлю а "ARM, 32bit", здесь уберите, мешает всем

[ViKo]

port->BSRR = state?(msk):(msk<<16);
...
компиляется в минимум,- жаль, редко, когда в две-это при интенсивных операциях -инструкции

Это если один бит задавать. А по началу можно весь порт установить в нужное состояние.

[_Pasha]

_Pasha, так в каком случае индуистский подход с ручными отступами в структурах может привести к неправильному результату? Или здесь речь чисто об эстетике?

Вообще-то подозрения в выравнивании - не мои. Если MrYuran сталкивался, думаю, он поделится.
Хотя, странно -fpack-struct=8 должен бы, как представляется...
Я только выразил недоумение по поводу головоломок там, где их быть не должно, при передвижении на круглых колесах, тсз.

Сообщение отредактировал _Pasha - Oct 17 2012, 18:52

[AHTOXA]

Это если один бит задавать. А по началу можно весь порт установить в нужное состояние.

Вообще-то для этого есть ODR

[_Pasha]

Это если один бит задавать. А по началу можно весь порт установить в нужное состояние.

Да хоть 100! Из 16-ти

Сообщение отредактировал _Pasha - Oct 17 2012, 18:57

[ViKo]

Вообще-то для этого есть ODR

Точно! Что-то я упустил его из виду! Вот спасибо! Пойду поправлю нафиг. Еще один шаг к совершенству.
А он у них (индусов) - тоже, 32-х разрядный!
Кстати, если про BSRR в Ref Manual написано "These bits are write-only and can be accessed in word, half-word or byte mode", то про доступ к ODR - молчок. Можно ли туда послать 16 битовое число?

Про IDR написано конкретно: These bits are read-only and can be accessed in word mode only.

[AHTOXA]

Вообще-то подозрения в выравнивании - не мои. Если MrYuran сталкивался, думаю, он поделится.

А в чём тогда "правильность" кода с union-ами?

Хотя, странно -fpack-struct=8 должен бы, как представляется...

Как я понял, -fpack-struct[=x] может только сильнее упаковать структуру. Проредить её может __attribute__ ((aligned (x))). Но его нужно явно указывать для члена структуры, случайно так не сделать.

[_Pasha]

А в чём тогда "правильность" кода с union-ами?

В данном случае - чисто йуридически

warning: #1441-D: nonstandard cast on lvalue

Где оно выползет боком - фантазии не хватает представить.
Для АРМов сумасшедшие компиляторы а-ля CodeVision для АВРок - существуют?
Если бы были - там бы и повылезло.

Сообщение отредактировал _Pasha - Oct 17 2012, 19:20

[ViKo]

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

Нигде. Только сон будет менее спокойным.
P.S. Видно по результатам компиляции - все нормально.

[Дмитриос]

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

Простите а вот под какой контроллер вы так сделали?

[_Pasha]

Простите а вот под какой контроллер вы так сделали?

STM32f100
Но, сделал - и пожалел. Надо сразу базу данных заводить и оттуда генерить. Писанина - плохой стиль.

[Дмитриос]

STM32f100
Но, сделал - и пожалел. Надо сразу базу данных заводить и оттуда генерить. Писанина - плохой стиль.

А разве производитель CMSIS ные либы со структурами не создаёт для регистров данного контроллера или у Вас свои какие-то структуры?

[_Pasha]

А разве производитель CMSIS ные либы со структурами не создаёт для регистров данного контроллера или у Вас свои какие-то структуры?

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

[AHTOXA]

В данном случае - чисто йуридически

Да нет же, я не об этом! Там ViKo просто не то не к тому привёл.
Я вот о чём. Чем ваш вариант

Код

typedef struct
{
  __IO uint32_t DR;
  union
{
  __IO uint8_t  reg8bit;
  uint32_t IDR_space;
} IDR;
  __IO uint32_t CR;
} CRC_TypeDef;

лучше индуистского варианта

Код

typedef struct
{
  __IO uint32_t DR;
  __IO uint8_t  reg8bit;
  __IO uint8_t  spacer;
  __IO uint16_t  spacer2;
  __IO uint32_t CR;
} CRC_TypeDef;

?

[MrYuran]

Вообще-то подозрения в выравнивании - не мои. Если MrYuran сталкивался, думаю, он поделится.

Сталкивался, не то слово.
MSPGCC образца 2008 года и iostructures.h
Причем, там явно было указано __attribute__ (("packed")) под каждой структурой, однако ж..
После серии необъяснимых чудес пришлось лезть в листинг и сверять адреса регистров.
Помогло только -fpack-struct, когда все структуры принудительно упаковывались.
После того все переписал на макросы Волкова.
Конечно, не так красиво, зато работает железно.

Хотя, сейчас поглядел...

Код

#if defined(__MSP430_HAS_PORT0__)
struct port0_t {
  ioregister_t    in;    /* Input */
  ioregister_t    out;    /* Output */
  ioregister_t    dir;    /* Direction */
  ioregister_t    ifg;    /* Interrupt Flag */
  ioregister_t    ies;    /* Interrupt Edge Select */
  ioregister_t    ie;    /* Interrupt Enable */
};

__MSP430_EXTERN__ struct port0_t port0 asm("0x0010");
#endif

Здесь почему-то упаковки нет.. Странно..
Это в корне меняет дело, а я на компилятор грешил.
Но суть то этого не меняется. Автоматически выровненная структура "прореживается" и все адреса сползают.

[AHTOXA]

Это в корне меняет дело
...
Но суть то этого не меняется.

Жжоте
Тем не менее. test.c:

Код

typedef struct
{
    unsigned char a;
    unsigned char b;
}str;

char zzz[1 - 2*(sizeof(str) != 2)];

gcc -c test.c - порядок.
avr-gcc -c test.c - порядок.
arm-kgp-gcc -c test.c - порядок.
arm-none-eabi-gcc -c test.c - порядок.
msp430-gcc -c test.c - порядок.

Что надо сделать, чтобы "проредило"?

[MrYuran]

Что надо сделать, чтобы "проредило"?

Я не знаю, что надо сделать, но точно знаю теперь, чего не надо..
Не надо использовать такие структуры без принудительной упаковки, во избежание.
Мне совершенно было не смешно, когда port1.out.pin3 = 1 махал битами в регистре dir вместо out (а это ещё надо было найти)

[Палыч]

Что надо сделать, чтобы "проредило"?

Вставить #pragma pack(n) или указать транслятору -fpack-struct=n cо значением n отличным от 1.
К сожалению, в документации на gcc нигде нет упоминания: какое значение n (величина выравнивания) принято "по-умолчанию"...

[_Pasha]

Да нет же, я не об этом! Там ViKo просто не то не к тому привёл.

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

[AHTOXA]

Я не знаю, что надо сделать, но точно знаю теперь, чего не надо..
Не надо использовать такие структуры без принудительной упаковки, во избежание.
Мне совершенно было не смешно, когда port1.out.pin3 = 1 махал битами в регистре dir вместо out (а это ещё надо было найти)

Скорее всего был локальный глюк какой-то конкретной версии mspgcc. Хотя принудительная упаковка - дело несложное, можно и её добавить, для пущей уверенности.

Вставить #pragma pack(n) или указать транслятору -fpack-struct=n cо значением n отличным от 1.
К сожалению, в документации на gcc нигде нет упоминания: какое значение n (величина выравнивания) принято "по-умолчанию"...

Нет, ничего из этого не увеличивает размер структуры. Проверил и с #pragma pack(x), и с -fpack-struct=x (x={4,8,16,32}), и с ними обоими одновременно.
До кучи проверил __attribute__ ((packed)) и __attribute__ ((aligned (x))) для типа.
Размер структуры равен 2, как я не извращался
Единственный вариант, который изменил размер, был вот такой:

Код

typedef struct
{
    unsigned char a __attribute__ ((aligned (8)));
    unsigned char b __attribute__ ((aligned (8)));
}str;

Но этот вариант не страшен, потому что явно указывать alignment там, где он не нужен, мы не будем.

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

А, вон оно что! Теперь понял

[ViKo]

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

Приведение типов - не хак. А осознанная необходимость. Я не с дырами борюсь, их у меня нет. А хочу писать не только 8-битовыми словами, но и 16-битовыми, 32-битовыми. Cortex-M это позволяет делать, начиная с любого адреса. Тем более, регистры микроконтроллера (или контроллера ЖКИ, который использую) и так выровнены по адресам.
Приведение типов указателя - обычное дело.

[Палыч]

Нет, ничего из этого не увеличивает размер структуры.

А теперь попробуйте проверить на такой структуре:

Код

typedef struct
{
    unsigned char a;
    unsigned int  b;
    unsigned char c;
}str;

[XVR]

Вообще то компиляторы упаковывают структуры не от их [компилятора] большого желания, а от требования выполнить ограничения по выравниванию для полей этих самых структур. Так что, если у вас в структуре нет полей с требованиями по выравниванию (например у вас там все char) - то ничего выравниваться и не будет. А вот если есть - то перед этим полем может появится дыра, и вся структура в целом получит ограничение по выравниванию, как для этого поля (что в свою очередь может добавить дыру и в конце структуры)
Например (предполагаю требования по выравниванию на размер поля):

Код

struct {
int8_t f8;
int16_t f16;
int32_t f32;
int8_t  f8_2;
};
// Превратится в
struct {
int8_t f8;
int   :8; // Выравнивание для f16 на границу 2х байтов
int16_t f16;
int  :16; // Выравнивание для f32 на границу 4х байтов
int32_t f32;
int8_t f8_2;
int :24; // Выравнивание размера всей структуры, как требует поле f32
};

[ViKo]

int :16; // Выравнивание для f32 на границу 4х байтов

лишнее

[_Pasha]

Приведение типов - не хак. А осознанная необходимость.
***
Cortex-M это позволяет делать, начиная с любого адреса.

А сколько воплей у народа по поводу невыровненного доступа на AT91** например! Там не особо позволяет 7tdmi.

лишнее

Оно уже для другого: читаем программу и если чего-то надо добавить, сразу видим, сколько бит осталось.

[AHTOXA]

А теперь попробуйте проверить на такой структуре:

Да, но речь шла о структурах, уже имеющих вручную сформированные отступы, типа такой:

Код

typedef struct
{
    uint8_t a;
    uint8_t padder1;    // - отступ
    uint16_t b;
    uint16_t padder2;  // - отступ
    uint32_t c;
}str;

Такие структуры используются, в частности, в заголовочных файлах от ST для описания периферии процессоров STM32. И меня интересует вопрос, могут ли такие структуры при каких-либо условиях перестать соответствовать описываемой ими периферии.
Пока получается, что всё нормально, соответствуют при любых ключах компиляции. (Ну, кроме непонятного случая, описанного MrYuran-ом)

[XVR]

лишнее

Да, точно. Просчитался

[esaulenka]

Вставить #pragma pack(n) или указать транслятору -fpack-struct=n cо значением n отличным от 1.

Раз тут пошли "страшные истории"...
pragma pack(n) надо обязательно закрывать pragma pack()
При включении заголовка с незакрытой прагмой такие интересные косяки проявляются - все структуры в одном модуле сами собой "упаковываются", а в другом - остаются неупакованными, в зависимости от последовательности #include.

Пример для наглядности:

Код

a.h:
#pragma pack (1)

b.h
typedef struct .... b_struct;

a.c
#include "a.h"
#include "b.h"
b_struct A;

b.h
#include "b.h"
b_struct B;

Так вот, A и B получились РАЗНЫЕ, хотя этого вряд-ли кто-то добивался :-)
Короче, плохая это прагма, не ленитесь писать атрибуты для каждой структуры.

[ReAl]

Пока получается, что всё нормально, соответствуют при любых ключах компиляции. (Ну, кроме непонятного случая, описанного MrYuran-ом)

Там, я так понял, ещё битовые поля были в подструктурах ioregister_t.
Что-то могло и на этом набежать.
Скажем,

Код

typedef {
    unsigned f : 1;
} flag_t;

typedef {
    flag_t a;
    flag_t b;
} flags2_t;

структура flags2_t займёт 2*sizeof(unsigned), а не один байт. Причём никакие pack не помогут.

[_pv]

Короче, плохая это прагма, не ленитесь писать атрибуты для каждой структуры

а если есть некая структура

Код

typedef struct{
  u8 b;
  u32 c;  
  u8 d;
  u16 a;  
} t_struct_A;

и указатель

Код

t_struct_A * p;

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

Код

u8 buff[100500];
p = &buff[17];

в каком именно месте и какие прагмы должны стоять чтобы p->c = 0xABCD1234; нормально работало всегда и везде?
или так лучше вообще не делать, а данные просто макросами по байтам по смещениям вытаскивать чтобы ни от платформы ни от компилятора не зависеть?

[AHTOXA]

Там, я так понял, ещё битовые поля были в подструктурах ioregister_t.
Что-то могло и на этом набежать.

Наверное.
Ну а в результате, какой будет вывод? Можно безбоязненно пользоваться структурами от ST? Или ждать, когда _Pasha сделает базу данных?

[ViKo]

Можно безбоязненно пользоваться структурами от ST?

Если программируем аппаратные средства микроконтроллеров STM32xxx, то используются не структуры, а указатели на типы структур, расположенные по фиксированным адресам.
Если просто пользуемся структурами, подобными предложенным ST, то не все ли равно, как упакованы данные? Куда записали, оттуда и прочитаем.

[AHTOXA]

Если программируем аппаратные средства микроконтроллеров STM32xxx, то используются не структуры, а указатели на типы структур, расположенные по фиксированным адресам.

Какая нафиг разница? Если структура вдруг разъедется, то мы промахнёмся мимо нужного регистра и по указателю

[ViKo]

Какая нафиг разница? Если структура вдруг разъедется, то мы промахнёмся мимо нужного регистра и по указателю

Как же она разъедется, если указателю передан конкретный адрес! А дыры зарезервированы неиспользуемыми переменными.
P.S. Мы же ее (структуру) уже разъехали разъездили раскатали растянули.

[AHTOXA]

Мы же ее (структуру) уже разъехали разъездили раскатали растянули.

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

[_Pasha]

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

Самое простое - не морочить, а заложить где-то assert, только вот что лучше проверять: небось, sizeof какой-то тестовой структуры, не обязательно прям-таки осмысленной и привязанной к реальным портам, но с использованием всех индуистских _IO32 и прочая.

[ViKo]

К счастью, в железе STM32 адреса устройств уже распределены так, что "упаковываются" в структурах согласно своему естественному размеру, int16_t по границам полуслова, int32_t по границам слова. Во всяком случае, я не заметил, чтобы где-то в stm32fxx.h было не так. Поэтому, если не насиловать компилятор прагмами pack(n), ничто расползаться не должно.
А __packed может только утоптать структуру, но не раздвинуть ее. А от этого мы уже защитились RESERVED.
Так, вроде?

[_Pasha]

К счастью, в железе STM32 [...]

В принципе, тут зацепились мы за платформенно-независимый вопрос.

Поэтому, если не насиловать компилятор прагмами pack(n)

... а также приведением типов указателей на элемент структуры ...

[=GM=]

Допустим, имеется структура из байтов. Хочу инициализировать сразу 2 байта 16-битовым числом, или сразу 4 байта 32-битовым числом. Привожу указатель к нужному типу

Похоже, при формировании структуры си-компилятор находит элемент с максимальной длиной и выделяет каждому элементу структуры размер памяти, равный максимальной длине. По крайней мере, для кейловского компилятора я это доказал. Выделил структуру
typedef struct
{
unsigned long VARA;
unsigned char VARB;
unsigned int VARC;
}
CRCSTRUCT;

CRCSTRUCT STRD;

и в дибаггере стал туда писать побайтно, начиная с VARА. В VARА записалось 4 байта, как и ожидалось, в VARВ записался один байт, остальные три писались в никуда и не отображались, в VARC записалось два байта, остальные записались в никуда.

Так что дырки в структурах всегда будут, если структура содержит элементы разной длины.

[_Pasha]

Есть Грабля!

CODE

typedef struct
{
char id[2];
uint32_t size;
char reserved[4];
uint32_t offset;
uint32_t bmp_infolen;
uint32_t width;
uint32_t height;
uint16_t planes;//number of
uint16_t bits_per_pix;
uint32_t compress_type;
uint32_t picture_size;
uint32_t Hresolution;
uint32_t Vresolution;
uint32_t used_colors;
uint32_t important_colors;
} bmp_header_t;

Компилим

Код

gcc версия 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

с дефолтными настройками code::blocks (уверяю, там ничего страшного нету, выравнивание нигде принудительно не включено)
Пишет после bmp_header.id два нулевых байта, также при выводе его размера показывает 56 байт супротив 54-х.
В общем, подарок для АНТОХИ.
ЗЫ причем, сгенеренный и исходный BMP отличаются ровно на этих 2 байта
PPS добавили #pragma pack(1) - получили всё, что надо. 54 байта.
Оттакот!
ppps Что-то пользоваться таким ГЦЦ расхотелось...

Сообщение отредактировал _Pasha - Nov 9 2012, 19:11

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

CODE

typedef struct
{
    char        id[2];
    uint32_t    size;

И что же вы ожидали (надеюсь, это был не AVR или MSP430)?

[AHTOXA]

Есть Грабля!

Да вроде не особо, uint32_t выровняли на 4 байта. Не вижу криминала

[_Pasha]

Да вроде не особо, uint32_t выровняли на 4 байта. Не вижу криминала

Разобрался... чего-то вбил себе в голову, что uint16_t там не подряд идут. И непонятно, чего там так, там эдак. Тогда всё правильно.

Сообщение отредактировал _Pasha - Nov 9 2012, 19:44

[ViKo]

Всплыл вопрос, кажется, подойдет в эту тему.
Создаю суперструктуру из нескольких разных структур. В каждой из структур переменные разного размера кидаю, как попало. Не знаю, создаются дыры или нет, но пока использовал структуры по-отдельности, проблем не было. Keil знает, куда положил, и откуда брать. Для Cortex-M нет проблем. В суперструктуре должно быть аналогично.

Теперь хочу копировать суперструктуру в другую, такую же (backup). Хочу делать это 32-битовыми пересылками. Кроме того, хочу вычислять аппаратно CRC суперструктуры, туда тоже нужно посылать 32-битовые слова.
Задаю указателю на uint32 адрес суперструктуры (uint32_t *)&Ctrl. Вычисляю ее размер в словах (!) size(Ctrl_t) / 4. И так собираюсь использовать.

Вопросы:
1. Что гарантирует, что вся суперструктура разместится по выровненному до слова адресу? Что будет, если первый элемент - 8-битовый?
2. Как задать, чтобы ее размер был равен целому числу слов? Пока напихал несколько пустых байтов, каждая мелкая структура - по 2-4-8 байтов, общее количество 44 байта (но, может, есть и дыры двухбайтовые?). В конце суперструктуры задаю 32-битовую CRC, это гарантирует выравнивание по словам, и целое число слов?

[MrYuran]

1. Что гарантирует, что вся суперструктура разместится по выровненному до слова адресу? Что будет, если первый элемент - 8-битовый?

Если явно определено выравнивание (pack или aligned), то вроде как должно.

[ViKo]

Почитал здесь - http://www.keil.com/support/man/docs/armcc...he.htm#Cihbbgii
Похоже, ничего делать не надо.

Если явно определено выравнивание (pack или aligned), то вроде как должно.

Похоже, лучше, наоборот, ничего не задавать. Тогда само разместится ровненько.

[ig_z]

2. Как задать, чтобы ее размер был равен целому числу слов?

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

[ViKo]

Запустил компиляцию с опцией --remarks.
Вижу:
enum занимают по 32 бита! Неоправданная роскошь.
К структуре с enum и 3-мя uint_16 добавилось... видимо 2 байта в конце.
По структуре Ctrl никаких замечаний не увидел.

Добавил uint8_t в конец Ctrl. Получил замечание, что добавило padding.
Делаю вывод - ничего не бойся, не проси... Сам Кейл придет и принесет.

[PheeL]

enum занимают по 32 бита! Неоправданная роскошь.

Каждый из элементов enum - это int. Так что если машинное слово 32-х разрядное, то всё верно.

[ViKo]

Каждый из элементов enum - это int. Так что если машинное слово 32-х разрядное, то всё верно.

Да, верно. Просто я об этом не задумывался. Да оно и нашлось всего в одном месте. Там и не сам enum стоял, а производный тип - typedef enum {...} ... Заменю на uint16_t и сэкономлю 4 байта!

Что любопытно. Имею в структуре 2 байта, в первом - битовые поля, во втором - uint8_t (вообще, reserv, для выше сказанного выравнивания). Так вот, такую 2-байтовую структуру Keil размещает в суперструктуре, не выравнивая по 2-байтовой границе. Как и написано по вышеприведенной ссылке, структура выравнивается по границе ее наибольшего члена.

[XVR]

1. Что гарантирует, что вся суперструктура разместится по выровненному до слова адресу?

Компилятор гарантирует, что любое поле структуры (в том числе и поля вложенных структур) будет выровнено на его размер. Так же гарантируется, что это будет так и для массива структур. Отсюда автоматически следует, что сама структура всегда будет выровнена по ее полю с максимальным размером, и размер структуры тоже будет кратен размеру этого поля.

Что будет, если первый элемент - 8-битовый?

Не важно, какой первый. Главное, что бы внутри был хотя бы один int

В конце суперструктуры задаю 32-битовую CRC, это гарантирует выравнивание по словам, и целое число слов?

Да

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

В конце суперструктуры задаю 32-битовую CRC, это гарантирует выравнивание по словам, и целое число слов?

Как уже было сказано - да, гарантирует. Но все "дырки", оставшиеся от выравнивания полей, могут быть заполнены совершенно произвольным мусором. Учтите это при расчете CRC. Т.е. либо перед заполнением полей структуры обнуляйте выделенную под нее память при помощи memset, либо считайте CRC конкретных полей, а не всей памяти струткуры, либо размещайте поля так, чтобы не между ними не образовывалось "дырок".

[AHTOXA]

Но все "дырки", оставшиеся от выравнивания полей, могут быть заполнены совершенно произвольным мусором. Учтите это при расчете CRC.

Да, как-то я напоролся на такое. Была структура, в конце структуры crc16. При инициализации проверялось crc, и, в случае несовпадения, значениям структуры присваивались значения по умолчанию.
Всё это прекрасно работало, до тех пор, пока я не поменял размер одного члена структуры с uint8_t на uint16_t. После этой замены моя программа стала дурить. Оказалось, что при смене размера члена общий размер структуры не изменился, crc16 тоже совпал. А вот значение этого члена получилось недопустимо большое (за счёт добавленного байта).