Здравствуйте.

Прошу подсказки.

С целью удобства и лучшей читабельности необходимо объединить биты портов микроконтроллера в один структурный тип или объединение.

Биты находятся в разных портах и не последовательно.

Не пойму как назначить адрес бита порта к "битовому типу" структуры.

Заранее благодарен

Никак

Вы всегда смотрите, как именно ваши фантазии будет реализовыватcя на данной системе команд. Имеет ли смысл?

Вариант с опросом разных битов в разных портах не очень удобен.

Я как -то делал для одного порта - присваивал структуре адрес регистра саециального назначения с помощью директивы #byte в компиляторе CCS для пиков.

Сейчас задача для нека, используя ИАР

Для читаемости можно оформить доступ к битам в разных портах как макрос примерно так:

#define OUT(x) do{код доступа к битам в разных портах }while(0)

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

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

Прости, господи , а может просто надо не только "читать современные книги", но и читать просто книги, и просто думать, когда пишешь? Причем пишешь не только макросы, а то возникнут "грабли".

Такие книжки читать как раз не нужно, ИМХО. Ибо это из категории вредных советов.

Да нет, сами по себе советы вместо #define использовать const и темплейты - правильные.
Просто в тех книгах речь идёт о С++ и типичных его применениях - для ваяния многомегабайтных монстров. А тут случай практически противоположный - манипуляции битами на самом нижнем уровне, никакой переносимости не требуется по определению, зато важна эффективность.
Но, разумеется, хотелось бы собрать в одном месте все зависимости от номеров битов в портах, чтобы при правках не искать их по всей программе.

Альтернатива - написать пару функций для чтения и для записи, а для эффективности инлайнить их.

Мне представляется, что:
1. Есть программисты - одиночки, пишущие и поддерживающие проект самостоятельно.
2. Программисты, либо работающие в коллективе разработчиков, либо вынужденные учитывать тот факт, что их проект может/будет сопровождаться и развиваться другими людьми.

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

Описываю весь доступ к портам через макросы в одном h-файле и не парюсь.
В прочих файлах НИКАКОГО упоминания о портах, только макросы с осмысленными названиями. Просто для понимания. Существенно упрощает портирование.
К сожалению, есть проблема инлайнить функции, определенные в других модулях, теоретически можно тоже через #include, но это уж точно на изврат похоже.

Это не изврат, а требование компилятора к видимости тела inline функции в том модуле, где вы хотите, чтобы эта функция была встроена. О чем многократно писалось на форуме.

На С++ можно с помощью перезагрузки операции присваивания. И потом объеденения полей в класс. Можно еще шаблоны прифигачить

Только IMHO лучше, как тут уже писали, функции определить.

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

А почему все макросы в одном h-файле можно поместить, а все inline функции в одном h-файле нельзя? Професиональные принципы не позволяют?

Я бы сделал так:

#define UP(port, bit) port |= (1<<bit)
#define DOWN(port, bit) port &= ~(1<<bit)

Далее:

#define LIGHT P1OUT,1
#define MOTOR P2OUT,3
#define BEEPER P3OUT,2

Итого имеем:

UP(LIGHT);
DOWN(MOTOR);
UP(BEEPER);

Названия регистров взял от МСП, как наиболее актуального для меня

Если хочется именно структуры, то надо немного подумать.
Например, определить структуру Pin{}, в которой указать порт, номер пина и т.д. Например, забить туда все регистры порта (OUT,DIR,IE,SEL).
А потом уже эту структуру включать внутрь других структур.
Но всё равно без макросов не обойтись.
Либо класс рисовать.

Хотя, если взять тот же МСП, то там в io.h порты расписаны в том числе и как структуры, и можно написать
port1.out.pin3 = 1;
port2.out.pin1 = 0;
Тогда всё еще проще:
#define MOTOR port1.out.pin3;
...
MOTOR = 1;
C инициализацией других регистров порта опять же, нужно отдельно думать.

Напрасно Вы так - вовсе не изврат, а очень полезный в некоторых случаях прием.

ОК, я подумаю. Хотелось бы уточнить случаи.

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

Если же функция вырождается в дерганье выводом или считывание его состояния, то объясните мне плз, в чем преимущество инлайновой функции по сравнению с простейшим макросом:
#define ON_BACKLIGHT (P1OUT|=P1_BACKLIGHT),
где #define P1_BACKLIGHT 0x02 //output

Например, есть у меня в модуле display такая функция:


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

Это значит, что где-то кто-то может встретить в вашей программе:


Вы сами-то как оцениваете читабельность такого выражения?

ОК, спасибо. Видимо, не сталкивался.
Но в таком виде функция не инклюдится, или я не знаю эту среду/компилятор?


Супер! Превосходная ! Ни у кого такого нет!
"Включить подсвет", насколько мне известно...
Большие буквы, отсутствие скобок -> значит это макрос для работы с портами -> см файл project_ports.h
Лет пят-шесть так работаю, маразм наступает, но вот с этим пока проблем не было.

Вы имеете в виду __forceinline? Это от RVCT.


Ну не знаю, не могу разделить Ваши восторги. Понятно, что при помощи макросов можно заставить 'C' выглядеть как что-то совсем другое, но, ИМХО, лучше так не делать.

Ну это, условный рефлекс, наверное.

Нет, я не только это я имею ввиду. Как тут отмечалось, чтобы функция инлайнилась, нужно, чтобы ее текст попадал в область видимости, то есть ее текст должен быть перенесен в модуль, где она используется, как то так:
#define DISPL_SET_DOT_ALPHA __forceinline void disp_set_dot_alpha(u_int x, u_int y, DISP_COLOR color, u_char alpha) \
{ \
u_int c0, c1, mask; \
if(alpha > 0) \
{ \
...


Так сложилось в жизни, что был период turbo pascal 6.0/ Pascal Borland 7.0 for embedded applications, so I don't follow strong rules in C

Только не так, Боже упаси! Функция в header'е display.h, который и подключается.

Форум "электроникс" - 1) достаточно модерируемый и 2) самоорганизующийся форум.
Я удивлен тем фактом, что мне приходится отметать Ваш переход на какие-то посторонние от техники аспекты.
Или Вы так зашорены, что больше нечего сказать?


А, ну да, конечно...

1. При чем тут зашоренность. Абсолютное большинство программистов, увидев сразу поймет, что вызывается некая функция, т.е. некая локальная обработка данных, а может означать все что угодно. Может это чтение из глобальной переменной ABC в стиле уважаемого гуру zltigo, a может вызов макро.
2. Есть понятие "стиль программирования". Мне кажется, что "стильно" написанная программа это такая, которая легко читается и сопровождается, и не только автором.

Всем большое спасибо за помощь

Небольшой пример для иллюстрации "прелестей" макро.

где-то в программе напишем:


Понятно, что такое можно написать после долгих праздников, но это может быть и результатом типичной ляпы типа "copy/paste".
Очевидно, что это ляпа, но препроцессор это преобразует в

и компилятор не моргнув никакими error/warning откомпилирует. Очевидно, что это ляпа, но сколько времени вы будете ее искать?

Ежели UP оформить в виде inline функции


компилятор тут же выдаст что-нибудь типа '+' : illegal operand of type 'void' с указанием номера строки (VS 2008).

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

Ну, с тем же успехом можно сделать и в виде дефайна:

Отсутствующте скобочки они, конечно явно заставляют задуматься а что это такое? Причем задуматься без всякой на то надобности .
Для подчеркивания того, что это макрос достаточным является запись большими буквами (хотя для "функций" я этим практически не пользуюсь - никакой информации это собственно не несет) естественным для 'C' является
on_backlight();
Ну или ксли хочется обратить внимание (обычно совсем без надобности) что это псевдофункция:
ON_BACKLIGHT();
Но и это излишество в вашем случае. Хотя иногда, явно полезно, например если что-то написано в незамысловатом стиле




Точнее так :

Да-да, copy-paste, в первый раз и "char" забыл убрать

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

Согласитесь уважаемый гуру, что написать "дуракоустойчивый" макрос сложнее (хотя бы с точки зрения отладки) эквивалентной inline функции.

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

Я то опираюсь на свою статистику - она более чем удовлетворительная.
И вообще, существуют правила, вроде бы очевидные и понятные, например правила проверки равенства (константа на первом месте), затрудняющие чтение программы (по крайней мере лично у меня).
Ну а скобочки ... говорю - из Паскаля я. Меня не заставляют задуматься. Те, кто использует мои тексты - тоже вроде не жалуются.
Хотя сомнение зародили, если такая точка зрения есть, ничего не стоит попробовать.

Кстати, указание inline, насколько я помню, не является безусловным и обязательным для компилятора, или?

Не является. Но, во-первых, есть прагмы/модификаторы, настоятельно рекомендующие это компилятору (типа упомянутого __forceinline для RV); во-вторых, вредительством и саботажем компилятор тоже заниматься не станет.

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

В общем согласен. Но только с оговорокой "легко читается и сопровождается людьми, имеющими определённый уровень подготовки". Ни в коем случае не всеми, кто написал "Hello, world!".
А то ведь и в "человеческих" языках есть всякие там сложноподчинённые предложения, идиомы с прочими тропами, не говорю уже о профессиональной терминологии - тоже ведь не всё сказанное всем понятно будет, причём не только тем, кто только начал язык осваивать, но и многим "носителям". И это нормально.
Я немного увожу в сторону от основной темы обсуждения, но когда начинается "указательную арифметику не использовать, плохо читается" и т.п. я думаю - может просто надо уровень читателей поднимать?
Ведь в "должно быть понятно" можно докатиться до уровня рекламы стирального порошка или там "ретоны".
Когда вижу как бы на С написанное
вместо
я просто поражаюсь - насколько надо не любить и не знать С, чтобы так писать. А если это политика "чтобы понятно было", то на кого рассчитывается? И сможет ли этот "кто" понять всю программу?

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

Оптимум где-то посредине, и, на мой взгляд, в случае с С в этот оптимум входит понимание возможностей и ограничений макросов, а не вера в то, что они вредны, почёрпнутая из агитации за С++, причём на примерах ошибок, которые более менее грамотный программист просто не должен уже совершать (а на уровне, на котором они совершаются, и на С++ ничего хорошего не будет написано). Уровень их использования, который обсуждается в этой теме, не должен приводить к каким-то ощутимым на фоне всей программы задержкам понимания текста. Любой знающий язык С, а не некое усечённое подмножество "разрешённое к применению в фирме" должен быстро с ним разобраться.
Это понимание требует какого-то своего опыта. Начинающим сразу с С++ и не собирающимся работать на С может и можно послабление дать. Но с учётом того, что они (теоретически) должны научиться понимать гораздо более сложные вещи - макросы такого уровня они должны понимать легко.

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

Duff's device в него, пожалуй, не включу (хотя для понимания сути switch это весьма полезный пример и он есть в упражнениях у Страуструпа в "Язык программирования С++", причём это упражнение с низким уровнем сложности).


Можно и без макросов и без указателей и без goto наворотить такое, что никто не разберёт и не сможет сопровождать. Точно так же, как и имея словарный запас в три сотни слов можно нести околесицу. Приведенный Вами пример настолько "букварный", что или он из букваря и взят, или написавшему этот код человеку надо наконец-то вдумчиво прочесть книжку по языку С.

Вы никогда не видели примеры "индусского" кода на java, где "корень всех зол" в виде макросов отсутствует?

Что бы Вы сказали, если бы кто-то привёл пример такого кода как доказательство того, что с java надо уходить на С ?

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

То на попытку применить эту функцию к порту будет выдано сообщение об ошибке. А так - она вообще ничего полезного не делает, так как модифицирует свой аргумент типа char.


Да, для avr-gcc можно написать
Но
1) для IAR это уже не прокатит, там по-другому описаны порты, типы volatile uint8_t * и volatile uint8_t & не подойдут.
А вот правильно написанный макрос UP будет работать и там, и там.
2) а с первого раза и inline-функцию не вышло написать правильно За что боролись?

Ага. Вроде бы это должно работать где угодно.
Но это уже совсем не С, так что может иметь отношение только к разговору о (не)применении макросов в С++, даже к C99 отношения не имеет, а, как тут в параллельной теме выяснилось, и С99 иногда непозволительная роскошь.

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

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



А уже потом где надо, эти функции с осмысленными названиями назначать структурам:



Зачем нужны всякие макросы и прочая фигня для работы с портами то?

====================
Кстати, об исходной теме и проблемах её автора :-)

В этой теме может что-то полезное найдётся.

Зачем нужна вся эта фигня для работы с портами то?

Как правило __работать__ с портами не нужно.
Нужно работать с какими-то внешними объектами, так уж получается что через порты. Порты - промежуточное звено, о котором лучше всего забыть вообще.
Упоминания о портах у меня заканчиваются в hal и нигде более в программе не вспоминаются.

А вместо декларируемого HAL для "объекта" получена просто заумная работа с отдельными битам . Вы не одиноки , а заумные HAL пишут с неменьшим "успехом" и на макросах. Уму не растяжимой "красоты" пример HAL можно глянуть в SimpliciTI от TI. Ну их еще можно понять - а нефиг читать и портировать - берите и пользуйте только с нашими продуктами, как есть.

HAL у меня не декларирует непосредственно объекты (объекты описываются уже в соответствующих им файлах).
HAL у меня отделяет программу от МК. (Двухступенчатый HAL получается). В примере выше, TFLOW_CONTROL описан не в HAL, а в uart.h, т.к. это объект связанный с UART'ом.

Если мне нужно включить реле1 то я предпочту написать

hal_RelayOn();

если зажечь зеленый светодиод, а не красный и не желтый.

hal_GreenLedOn();

вместо

SET_BIT( PORT_HZx, PIN_HZx);
CLR_BIT( PORT_HZy, PIN_HZy);

или других извратов.


В свою очередь, это дает возможность, легко управлять временем.
Например отключить реле __через 2 секунды__ после включения, я могу сразу же при включении реле:

hal_RelayOn();
Kernel_SetCb( hal_RelayOff, 2000, SEMA_NULL);

Ну и полностью забыть о GPIO портах как о классе, вне HAL.


на макросах такая конструкция
hal_RelayOn();
Kernel_SetCb( hal_RelayOff, 2000, SEMA_NULL);
непрокатит.

а почему не прокатит-то ?
почему макрос "Kernel_SetCb" не сможет укладывать countdown значение 2000 в соответствующую ячейку массива ?

Потому что Kernel_SetCb делает то что написано в названии - одноразово вызывает заданную функцию по таймауту или по событию в зависимости от того, что произойдет раньше.
Если вместо функции первым параметром дадите макрос (CLR/SET_PIN_X), думаю очевидно, что программа даже нескомпилится, т.к. у макроса не может быть адреса.

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

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


И даже для тех-же светодиодов уровень абстакции может, и я считаю- должен, быть заметно выше, нежели ON/OFF
void led_mode( Led_e led, Led_mode_e mode );
led_mode( LED_RED, LM_FLASH_1 );
Задается какой светодиод и десяток режимов миганий. Несклько десятков строк в отдельном файле посященном светодиодам. В файле без всяких слишком многоэтажных наворотов пишется, все , что нужно. Такой HAL, я понимаю.

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

Kernel у меня работает с функциями и с задачами а не с идентификаторами пинов.
Любое __действие__ в общем виде всегда можно описать функцией. Номером пина либо еще какой-то фигней, любое действие не опишешь.

Точно также как в примере с реле я работаю и с более сложными процессами:

modem_Dial();
Kernel_SetCb( modem_Dial, 60000, SEMA_NULL); // повторный дозвон через минуту если не удалось дозвониться.


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

Наверное пока не уловил, поэтому и переспрашиваю...
А может Вашему кернелу уже работать с объектами а не с отдельными сущностями ?
совсем не уловил почему countdown счетчик для пина должен принципиально отличаться от таково же для модема ?