[ViKo 1]

А неважно.

Выровняет по границе машинного слова (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 0]

Для того и вводятся резервные места, ну, как в 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;

 

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

[Артём__ 0]

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

Интересно, а чем же пользоваться?

Самому хидеры на процы делать?

[_Pasha 0]

Интересно, а чем же пользоваться?

Самому хидеры на процы делать?

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

Странно, но LPC такой ненависти не вызывают. Очень странно... :)

Вообще, я там сильно повыделывался - дал битовым полям осмысленные имена... там по-хорошему надо двуязычие, тоже на основе union{}- с сохранением мнемоники и с сохранением смысла... этот момент разрулю - будет тыщи три строк.

И вроде бы взять да и сделать базу в libreoffice base, чтоб генерило то,что надо... блин, лень забадала.

Изменено 17 октября, 2012 пользователем _Pasha

[AHTOXA 15]

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

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 1]

Ух как у меня все это перекликается... и с volatile, и со структурами

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

[ViKo 1]

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

...

Я тоже кинулся было править 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 1]

Итак, добавляю :)

есть две области в 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 0]

Я тоже кинулся было править 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);
}

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

Изменено 17 октября, 2012 пользователем _Pasha

[ViKo 1]

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

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

 

[AHTOXA 15]

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

Дык, индусы, кто ж ещё:) Причём битовые маски оставили как для 32-битного BSRR. (Это для F2xx.)

Я всё же такого не стерпел, и переписал это определение.

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

[toweroff 1]

Админы, я так понимаю, здесь свой колхоз :)

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

 

[ViKo 1]

port->BSRR = state?(msk):(msk<<16);

...

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

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

[_Pasha 0]

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

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

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

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

Изменено 17 октября, 2012 пользователем _Pasha

[AHTOXA 15]

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

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