Как лучше описать регистры, оставить как есть в uint32_t или в битовых полях Опции

[toweroff]

Доброго времени

Есть у меня некий хидер для LPC177x
Там описан volatile регистр, к примеру IOCON, потом регистр пина, к которым доступ примерно такой - LPC_IOCON->P0_0 = xxx;
Я тут устал считать биты, описал в виде полей типы вот так:

Код

typedef struct
{
    union
    {
        __IO uint32_t D_IOCON;
        struct
        {
            __IO uint32_t FUNC        : 3;
            __IO uint32_t MODE        : 2;
            __IO uint32_t HYS        : 1;
            __IO uint32_t INV        : 1;
                 uint32_t RESERVED0    : 2;
            __IO uint32_t SLEW        : 1;
            __IO uint32_t OD        : 1;
                 uint32_t RESERVED1    : 21;
        };
    };
} LPC_PIN_TypeD_TypeDef;

но, разумеется, из-за vilatile код генерится в два этапа:

Код

;;;75         LPC_IOCON->P2_24.FUNC = 0; // GPIO pin
00000c  4921              LDR      r1,|L1.148|
00000e  f8d12160          LDR      r2,[r1,#0x160]
000012  f0220207          BIC      r2,r2,#7
000016  f8c12160          STR      r2,[r1,#0x160]
;;;76         LPC_IOCON->P2_24.MODE = 2; // Pullup enabled
00001a  f8d12160          LDR      r2,[r1,#0x160]
00001e  f0220218          BIC      r2,r2,#0x18
000022  3210              ADDS     r2,r2,#0x10
000024  f8c12160          STR      r2,[r1,#0x160]

как можно заставить компилятор генерить код в один этап?

[ViKo]

А чем хуже, например, такой способ инициализации? Нужные биты описаны в стандартном заголовочном файле в виде uint32_t.

Код

  ADC1_2->CCR =
    ADC12_CCR_MULTI_0    * 0 |    // Multi ADC mode selection: Independent mode
    ADC12_CCR_DELAY_0    * 4 |    // Delay between 2 sampling phases: 5
    ADC12_CCR_DMACFG    * 0 |    // DMA configuration for multi-ADC mode: Circular
    ADC12_CCR_MDMA_0    * 0 |    // DMA mode for multi-ADC mode: disabled
    ADC12_CCR_CKMODE_0    * 1 |    // ADC clock mode: AHB / 1
    ADC12_CCR_VREFEN    * 1 |    // VREFINT enable
    ADC12_CCR_TSEN        * 0 |    // Temperature sensor enable
    ADC12_CCR_VBATEN    * 0;    // VBAT enable

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

А чем хуже, например, такой способ инициализации?

Позволю немного отшлифовать:

Код

ADC1_2->CCR = 0
    | ADC12_CCR_MULTI_0    * 0     // Multi ADC mode selection: Independent mode
    | ADC12_CCR_DELAY_0    * 4     // Delay between 2 sampling phases: 5
    | ADC12_CCR_DMACFG     * 0     // DMA configuration for multi-ADC mode: Circular
    | ADC12_CCR_MDMA_0     * 0     // DMA mode for multi-ADC mode: disabled
    | ADC12_CCR_CKMODE_0   * 1     // ADC clock mode: AHB / 1
    | ADC12_CCR_VREFEN     * 1     // VREFINT enable
    | ADC12_CCR_TSEN       * 0     // Temperature sensor enable
    | ADC12_CCR_VBATEN     * 0     // VBAT enable
   ;

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

[ViKo]

Позволю немного отшлифовать:
Так вы можете легко закомментировать любую строку значений. В том числе первую, последнюю и даже все.

А я не комментирую их. Просто умножаю на 0 ненужные биты.

[AlexandrY]

А я не комментирую их. Просто умножаю на 0 ненужные биты.

А в чем великий смысл умножения перед сдвигом?

Мой подход такой:

Код

  FTM1->QDCTRL  = 0
                  + LSHIFT(1, 7) // PHAFLTREN | Phase A Input Filter Enable
                  + LSHIFT(1, 6) // PHBFLTREN | Phase B Input Filter Enable
                  + LSHIFT(0, 5) // PHAPOL    | Phase A Input Polarity
                  + LSHIFT(0, 4) // PHBPOL    | Phase B Input Polarity
                  + LSHIFT(0, 3) // QUADMODE  | Quadrature Decoder Mode  | 0 Phase A and phase B encoding mode.
                  + LSHIFT(0, 2) // QUADIR    | Read Only. FTM Counter Direction in Quadrature Decoder Mode    | 1 Counting direction is increasing
                  + LSHIFT(0, 1) // TOFDIR    | Read Only. Timer Overflow Direction in Quadrature Decoder Mode | 1 TOF bit was set on the top of counting.
                  + LSHIFT(1, 0) // QUADEN    | Quadrature Decoder Mode Enable
;

Смысл в том чтобы максимально соответствоало мануалу как первоисточнику.
Все объявления битов которые достаются из хидеров средств разработки типа Keil, IAR и проч игнорирую.
Не видел еще полных и безошибочных хидеров.
Названия битов даю в коментариях и точно как в мануале. Определения битов тоже copy-paste из мануала.
В макросах стоят номера битовых позиций.
Итого:
все определение битов в одном месте, не надо искать где-то далеко правильно ли определены макросы битов, и вообще определять эти макросы,
номера позиций битов не надо конвертировать в цифры множителей, а можно брать прямо из мануала,
полная информация о битовых полях позволяет быстрее вспомнить контекст, соответсвенно быстрее поиск ошибок и легче модификация.

В RTOS я вижу также отказываются от попыток работы с со структурами с битовыми полями регистров. Потому как это уникальный источник проблем.

[AHTOXA]

Мой подход такой:

Код

  FTM1->QDCTRL  = 0
                  + LSHIFT(1, 7) // PHAFLTREN | Phase A Input Filter Enable
...;

А если вдруг потом вы обнаружите, что PHAFLTREN равно не 7, а 8, то будете перекапывать все свои исходники? Бр-рр.
Лучше, имхо, всё же выносить это в какие-нибудь хидеры:

Код

  FTM1->QDCTRL  = 0
                  | (1UL << PHAFLTREN) // Phase A Input Filter Enable
...;

(Обращаю внимание на UL, иначе могут быть неприятности со старшим битом.)

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

В RTOS я вижу также отказываются от попыток работы с со структурами с битовыми полями регистров. Потому как это уникальный источник проблем.

В какой именно из RTOS-ов вы это видите?

[AlexandrY]

А если вдруг потом вы обнаружите, что PHAFLTREN равно не 7, а 8, то будете перекапывать все свои исходники? Бр-рр.
Лучше, имхо, всё же выносить это в какие-нибудь хидеры:

В какой именно из RTOS-ов вы это видите?

Хм, так в этом и есть мировозренческое различие подходов.

Случись какая-либо ошибка на уровне периферии, что вы делаете в этом случае?
Ясное деле, перекапываете все исходники.
И приходится параноидально проверять всё и объявления битов в первую очередь.
В таких поисках время можно сэкономить если все деражать в одном месте не делая определения битов где-то еще в макросах.

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

Ну а само содержание комментариев отражает особенности мануалов. У производителей в чьих мануалах биты всегда указываются с паре со своими регистрами не нужно дополнительно именовать биты.
А у Freescale например везде оперируют только с голыми именами битов в описаниях. Ну тогда приходится в исходниках обязательно упоминать имена битов.

Оправдание определению битов в хидерах я вижу только в желании сохранить стилистический подход навязываемый разработчиками библиотек под Keil, IAR, GCC и т.д.
Но ИМХО стоит ломать их подход, хотябы даже для того чтобы сильно к ним не привязываться.

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

С битовыми полями вообще не работают BSP генерируемые инструментиами Freescale для MQX например.

[AHTOXA]

В таких поисках время можно сэкономить если все деражать в одном месте

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

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

Кошмар.

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

При наличии современных IDE - никакой разницы. Подношу мышку к названию бита - получаю всплывающую подсказку с его значением.

Т.е. цель не экономить процессорное время (причем на редких и однократных операциях), а экономить свое время.

Не вижу экономии, вижу как раз наоборот.

[AlexandrY]

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

Правильно, в каждом файле своя периферия. Гораздо быстрее прочитать название файла и понять для какой он периферии. Открыл и знаешь, что больше никаких файлов и зависимостей.
И не надо гадать где бы еще поискать источники влияния на периферию.

Кошмар.

Назовите хоть пару кофигурационных периферийных регистров которые вы больше 3-х раз где-то используете.

При наличии современных IDE - никакой разницы. Подношу мышку к названию бита - получаю всплывающую подсказку с его значением.

Ага навел мышку на макрос запомнил, навел мышку на другой опять запомнил, ... навел на десятый, а про первый уже и забыл. И так пол дня мышкой возить пока все не запомниться.
А зачем запоминать? Только ради призрачной надежды что когда-то получиться одновремено аж в трех местах изменить бит?
На моей практике такого как-то не удавалось.

Не вижу экономии, вижу как раз наоборот.

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

Но опытные тренеры говорят, что все профессионалы рано или поздно приходят к одной технике.
Программирую уже лет 15-ть, а вы?

[AHTOXA]

Правильно, в каждом файле своя периферия. Гораздо быстрее прочитать название файла и понять для какой он периферии. Открыл и знаешь, что больше никаких файлов и зависимостей.
И не надо гадать где бы еще поискать источники влияния на периферию.

Так и у меня может быть по файлу на каждую периферию. Это не суть. Суть в том, что у меня есть мнемоники/дефайны для битов/групп бит конфигурации, а у вас они циферками. Мои мнемоники - определены в одном файле, используются везде где надо. Ваши циферки - определены в каждом файле, где используются.
Ваш вариант:

Код

  FTM1->QDCTRL  = 0
                  + LSHIFT(1, 7) // PHAFLTREN | Phase A Input Filter Enable

Мой вариант:

Код

FTM1->QDCTRL  = 0
                  | (1UL << PHAFLTREN) // Phase A Input Filter Enable

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

Назовите хоть пару кофигурационных периферийных регистров которые вы больше 3-х раз где-то используете.

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

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

Зачем запоминать? Вы свои циферки запоминаете что ли? Какой кошмар

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

Я вот тоже не понимаю, зачем запоминать.

Но опытные тренеры говорят, что все профессионалы рано или поздно приходят к одной технике.
Программирую уже лет 15-ть, а вы?

Насколько я могу судить, практически все профессионалы, кроме вас, всё-таки избегают использования "magic numbers".
ЗЫ. Профессионально программирую уже более 20 лет. А до этого был любителем

[AlexandrY]

Насколько я могу судить, практически все профессионалы, кроме вас, всё-таки избегают использования "magic numbers".
ЗЫ. Профессионально программирую уже более 20 лет. А до этого был любителем

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

Я не поверю чтобы вы без мануала смогли бы в течении хотя бы 10-и минут что-то попрограммировать с использованием регистров в периферийных модулях.
Так если все равно перед вами постоянно открытый мануал, зачем еще скрывать биты за бессмысленными названиями?
Или таким образом закрепить ассоциативные связи в памяти?

Я не прикалываюсь, действительно интересно как структурировать исходники чтобы не перенапрягать мозг.
Скажем одно только рутинное переключенеие экрана с текстов на хидеры в процессе редактирования я уже считаю вредным, и рассеивающим внимание. А сколько сил уходит на придумывание именований дефайнов для битов? Это все надо учитывать.

20 лет программировать на C-и встраиваемые системы... Что-то мало правдоподобно.

[AHTOXA]

Магическими числа называют так потому что не ясен их смысл.

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

Я не поверю чтобы вы без мануала смогли бы в течении хотя бы 10-и минут что-то попрограммировать с использованием регистров в периферийных модулях.

Мануал открыт при написании хидера. Описываем регистр (адрес), описываем маски для полей регистра. Пишем коммент (копипастим из мануала). Всё. В дальнейшем мануал не нужен - у нас есть хидер.
Кроме того, важно не только удобство программирования, но и удобство сопровождения. А сопровождать гораздо удобнее мнемоники, нежели магические цифры. Искать по тексту - тоже удобнее мнемоники.

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

Что-то малоправдоподобно

[AlexandrY]

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

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

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

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

Кстати, вы знакомы с понятием "нормализация"? Вот, вынос дефайна в отдельный хидер - это как раз она и есть. Исключение дублирования информации.

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

Мануал открыт при написании хидера. Описываем регистр (адрес), описываем маски для полей регистра. Пишем коммент (копипастим из мануала). Всё. В дальнейшем мануал не нужен - у нас есть хидер.
Кроме того, важно не только удобство программирования, но и удобство сопровождения. А сопровождать гораздо удобнее мнемоники, нежели магические цифры. Искать по тексту - тоже удобнее мнемоники.

Вот в эти байки я и не верю, якобы хидеры заменяют мануал.
Сопровождение тоже этакий миф. Удобство сопровождения кому. Стороннему программисту?
Так стороннему программисту что угодно напиши он всегда будет плеваться.
А автору исходников мало что облегчит если он вздумает вдруг поменять скажем битовую маску в хидере. Все равно придется лезть во все исходники где она применялась и разбираться с каждым случаем.
Так что же тогда облегчают хидеры? (Еще напомню, что говорим только о битах периферии, а не о всем на свете )