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

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

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

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

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

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

Никак

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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