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

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


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


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

1. Убрать volatile (__IO) из структуры, добавить в объявление переменной;
2. Считать в не-volatile переменную, модифицировать, записать обратно в регистр:

1. Не спасает
2. Некошерно...

Вообще идея по удобству-то неплохая, т.к. сразу видно по полям, какого типа пин (Analog, Digital< USB и т.д.), но вот это двойное обращение портит всю картину. В принципе, делается оно один раз при инициализации, так что можно и оставить

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

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

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

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

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

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

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


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

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

Спасибо всем

С volatile действительно нужно быть аккуратнее в плане количества доступа
С объявлениями бит в хидерах кейла для LPC швах, их просто нет, так что либо писать самому, либо искать

AlexandrY, я тоже согласен с таким подходом, но в каментах добавил бы еще ширину полей

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

В остальном - те же достоинства, что у AlexandrY. Только я копирую описания битов из хидера.

По-моему, мой способ нагляднее. Чем сдвигать 1 на 0, а 0 на 1, я просто умножаю 0x00000001 на 1.
И макрос не нужен.

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

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

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

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

Зачем? Можете описать только те, которые нужны.
Лично я описываю все имеющиеся, для универсальности и простоты модификации.
Опять же, для группы битов я использую только одно умножение (одну строку).

Вот именно об этом я и говорил. "Подразумевает"
Ещё вот о чём подумал. Если бит/группа битов в данный момент не нужна, то вы умножите её на 0. Но ведь при этом у вас теряется информация, на сколько надо сдвигать/умножать! Если это несколько групп битов подряд, то даже из значений соседних ненулевых множителей вы не сможете понять, на сколько надо умножить тот или иной бит/группу битов. И придётся вам лезть в документацию...
С этой точки зрения сдвиги + умножения на 0/1 гораздо лучше.

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

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

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

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

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

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

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

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

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

Кошмар.

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

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

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


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



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



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

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

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


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

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

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

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

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

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

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

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

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

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

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




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


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


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

Если у вас в исходниках (в соответствующем хидере) продублировано описание регистров из мануала, то зачем мануал?
Опять же, поиск по исходникам обеспечивает IDE, не надо переключать внимание код<==>мануал.
Если правильно организовать имена, то автодополнение тоже очень помогает: пишу
FLASH->CR |= FLASH_CR_
, нажимаю комбинацию клавиш, вуяля, передо мной все нужные варианты.


Или банальная ошибка/опечатка. Скажете, с вами такого не бывает? Значит вы второй такой уникум в мире (после меня)


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


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


Какие-такие "все макросы"? Один дефайн, в одном файле. А вот вы помучаетесь.


Во-первых, память не бездонна. Во-вторых, незачем забивать её несущественными деталями. Номер бита - информация лишняя. Мне нужно взвести/сбросить бит разрешения работы (EN) в регистре BDCR, я просто пишу RCC->BDCR |= RCC_BDCR_RTCEN. И мне неважно, какой номер у этого регистра.


Если перепишете всё из мануала в хидер, то почему нет?


В первую очередь себе. Удобства сопровождения я описал уже несколько раз.


Зачем лезть во все исходники, где применялась маска? Исправлять нужно только в одном месте - где маска определялась. А в остальных местах её новое значение подставит препроцессор

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

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

превращается в шараду:

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

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

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

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

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

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

Это была гипербола, мне жаль, что вы не поняли.


Вы тоже начинали с PIC-ов?

AlexandrY, поздравляю, ваш тонкий троллинг уже даёт всходы.


Эот вы ещё маловато программируете, всего 15 лет. Вот после 20 лет вы поймёте, что у нашей памяти есть дно

Я так и не услышал от вас аргументов, чем этот подход лучше. И не услышу, по всей видимости.
Свои аргументы, чем этот подход хуже, я уже привёл.

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


Нет, с TMS32F28xx от Texas Instruments и LH75401 от тогда еще Phillips, если это имеет какое-то значение. С PIC приходится иметь дело всего в одном устройстве, и мне не особо нравятся эти моменты.

Я всё же попросил бы Вас об этом одолжении. Не все любят, когда им ТЫкают,особенно незнакомые люди, и интернеты - не исключение.

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

Спасибо, доктор! Как же я раньше такой больной то ходил. Попытки принижения собеседника при отсутствии аргументов - это обязательный элемент твоей вашей стратегии спора? _{Это - риторический вопрос.} Если уж притворяешся притворяетесь умным и вежливым человеком - так притворяйся притворяйтесь до конца.

Вы не воспринимайте близко к сердцу, действительно, остаивать магические числа - это, мягко говоря, странно. И случай такой можно назвать
клиническим, но это не означает, что вы не здоровы. Естественный процесс развития от простого к сложному. Магические числа - это самый первый этап.
Затем, если разработчик чувствует перспективу и не ленится, то найдет/напишет библиотеки и будет ими пользоваться. Вы же признались, что лень
в вас победила здравый смысл. Отсюда и диагнозы. Вот если бы вы не ленились - вы бы сделали по-другому?

Я показал лучшее решение в сообщении #4, но "опытным профессионалам" лень разобраться и оценить его по-достоинству. Обратите внимание на XX * N.

Чем это лучше, чем просто комментить строку? Закомментированная строка сразу видна в редакторе с подсветкой синтактсиса, что, имхо, является плюсом, т.к. сразу видно, что активно, а что нет. Или вы что-то иное, нежели механизм оперативного включения/выключения битов, имели в виду?

Иное. Хотя и с вашим утверждением не согласен. Умножил на 0, и знаешь, что этот бит в нуле. Нужна 1, заменил 0 на 1. Однообразие.
Имею же в виду следующее, покажу конкретно на примере из сообщения №4.

Из stm32f30x.h имеем

Из мануала на STM32F303xx

0x00000100 * 0x4 = 0x00000400
Таким образом, умножив маску младшего бита на номер режима, я задаю все нужные биты режима одним махом. Не нужно устанавливать/сбрасывать все биты по-отдельности. Получается не 32 строчки (о чем писалось в начале темы), а намного меньше, столько, сколько есть полей для выбора режимов (в некоторых исключительных случаях поля режимов разбиты на 2, один бит где-то в другом месте болтается, тогда приходится описывать его отдельно).
И тогда - пробежался взглядом по инициализации, и все установки - как на ладони.

Для демонстрации красоты способа, вот другой пример (табуляция сползает, надоело править!):

Поддержу в этом споре Антоху.
Есть системный подход и есть всё остальное...
Повторное использование кода - это благо и на этом в основном и зиждиться программирование.