возможно ли на Си, объединить биты регистров портов микроконтроллера Опции

[another_one]

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

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

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

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

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

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

[sergeeff]

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

[Herz]

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

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

[SSerge]

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

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

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

[Dog Pawlowa]

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

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

[aaarrr]

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

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

[Dog Pawlowa]

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

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

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

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

[aaarrr]

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

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

Код

__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)
    {
        c0 = color;
        if(alpha < DISP_MAX_ALPHA)
        {
            c1 = *((u_short*)&disp_frame + (y * DISP_WIDTH) + x);
            mask = 0x07e0f81f;
            c0 = (c0 | (c0 << 16)) & mask;
            c1 = (c1 | (c1 << 16)) & mask;
            c0 = ((c0 * alpha) >> 5) & mask;
            c1 = ((c1 * (DISP_MAX_ALPHA - alpha)) >> 5) & mask;
            c0 = c0 + c1;
            c0 |= c0 >> 16;
        }
        *((u_short*)&disp_frame + (y * DISP_WIDTH) + x) = c0;
    }
}

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

[Dog Pawlowa]

зато как инлайн функция существенно повышает производительность.

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

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

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

[sergeeff]

Супер! Превосходная ! Ни у кого такого нет!

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

[Dog Pawlowa]

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

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

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

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

[sergeeff]

Или Вы так зашорены, что больше нечего сказать?

1. При чем тут зашоренность. Абсолютное большинство программистов, увидев

Код

ABC()

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

Код

ABC;

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

[ReAl]

2. Есть понятие "стиль программирования". Мне кажется, что "стильно" написанная программа это такая, которая легко читается и сопровождается, и не только автором.

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

Код

  if( flag )
  {
    struct.member[index] = a;
  }
  else
  {
    struct.member[index] = b;
  }

вместо

Код

   struct.member[index] = flag ? a : b;

я просто поражаюсь - насколько надо не любить и не знать С, чтобы так писать. А если это политика "чтобы понятно было", то на кого рассчитывается? И сможет ли этот "кто" понять всю программу?

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

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

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

Код

a = (flag ? sin : cos)(fi);

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

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

Код

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

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

Код

UP(port,2) + 3;

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

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

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

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

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

Код

inline void UP(char port, char bit) {port &= ~(1<<bit);}

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


Да, для avr-gcc можно написать

Код

// для С99 так
static inline void UP( volatile uint8_t *port, uint8_t bit)
{
    *port |= 1 << bit;
}

// а для режима С++ ещё и так
static inline void UP2( volatile uint8_t& port, uint8_t bit)
{
    port |= 1 << bit;
}

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

Ага. Вроде бы это должно работать где угодно.

Код

template<typename PP> inline void
UP3( PP & port, uint8_t bit)
{
    port |= 1 << bit;
}

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

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

[sergeeff]

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

1. Я нигде не утверждал, что макрос - страшное, ужасное зло. Бывают случаи, когда только они и работают.
2. "Букварный пример" он на то и пример, чтобы просто показать "подводные камни" макропрограммирования.
3. Все очень быстро в пылу дисскуссии забывают изначальный вопрос автора топика.
4. Любую программу можно написать десятком разных способов. Не спроста Кнут назвал свои книги "Искусство программирования".
5. Примеры с разложенными по строкам if .. else и тернарный оператор ? в 99% случае компилятором генерируются в одинаковый машинный код. Тут, как говорится, на вкус и цвет...
6. В большинстве случаев (есть и исключения) книги по программированию написаны людьми лично принимавшими участие в больших и огромных проектах и не знакомиться с их практическим опытом просто не разумно.

[ReAl]

2. "Букварный пример" он на то и пример, чтобы просто показать "подводные камни" макропрограммирования.

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

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

5. Примеры с разложенными по строкам if .. else и тернарный оператор ? в 99% случае компилятором генерируются в одинаковый машинный код. Тут, как говорится, на вкус и цвет...

А я об эффективности кода и не говорил. Это иллюстрация к "упрощённый язык для объяснения школьнику" и "общение профессионалов".
Многострочный вариант читается так:

если флаг установлен, то такому-то элементу такого-то массива такой-то структуры присвоить а
если же он сброшен, то такому-то элементу такого-то массива такой-то структуры присвоить b
а, одной и той же структуры!
а, одного и того же массива!
а, и индекс одинаковый!
щас... да, точно, всё до буковки одинаково.
значит так, такому-то элементу такого-то массива такой-то структуры в зависимости от флага присвоить a или b

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

Так значит тут - "на вкус и цвет", а макросы - снижают читаемость и сопровождаемость текста?

[sergeeff]

Так значит тут - "на вкус и цвет", а макросы - снижают читаемость и сопровождаемость текста?

Макросы - это препроцессор, т.е. "до компилятора". Варианты if... и ? - компилятор. Вы лично часто изучаете листинг препроцессора? Уверен - почти никогда. Значит вы просто полагаетесь на то, что вы со своим многолетним опытом, ошибок при написании макросов не допускаете и препроцессор все сделал именно так, вы себе это представляете. А если ошибка есть, она трудноуловима (при одних данных есть, при других - нет, а еще хуже при одних типах данных - есть, при других - нет). Вам что больше по душе, чтобы компилятор вам хотя бы подсказывал про подобные потенциальные проблемы, или молча, по своему усмотрению чего-то там понаделал, а вы потом, "по вторичным половым признакам" аномального поведения программы это все вылавливали?