А если проц поменялся? У меня это просто:
hal_SPI0_Prepare();



Вы о чем? Какие отдельные сущности?
Kernel работает с ___функциями____ которые описывают ___любые___ действия любых объектов.


Блин... дак ничем он и не отличается.

Ну а если ничем не отличается, то легко реализуем с помощью макросов...
и очень даже эфективненько...

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

Что реализуемо с помощью макросов? Изобразите свой полет мысли, а то получается разговор слепого с глухим.


куда положить?


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

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

Если предусматривается какая-то более сложная логика, то это не совсем порт, а, скажем объект какой-то типа звукового сигнала со своими параметрами, или моргающего светодиода, как в примере zltigo. Для обслуживания такого "объекта" прописывается свой сервис в каком-нить бэкграунде. Его параметры устанавливаются типа так:
void Beep (unsigned int ms, char beeps_qty), после чего "приложение" забывает о существовании этого объекта. Типичная организация системы без ОС.

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

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

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

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


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

А что такое макрос?

не подумайте что у меня есть какие-то предубеждения к макросам, я их тоже пользую ;> но не для портов, а например так:



Когда точно уверен, что мне никогда не понадобится свойство функции от этого действия.

Ничего не мешает и подниматься на более высокие уровни абстракции HAL - пример со сведодиодом я лично приводил. В этом случае задача абстрагироваться от смены прцессора не ставилась, причина более чем проста - SPI все несколько разные и нагрузка у меня на них большая,посему совсем не хочется все SPI стричь под одну гребенку, дабы все выглядели в угоду HAL одинаково. Причем, как правило, равняясь по слабейшему, они будут выглядеть одинаково уродливо . Даже на более высоком уровне абстракции "драйвер" не всегда несколько контроллеров хорошо стригутся под одну гребенку. Много чего обычно приходится придумвать для эффективной работы не вообще, например, "SPI" (про разные MAC, CAN,... вообще молчу) а "конкретного SPI" и на фоне этих работ, меня, честно говоря, совсем не волнуют "пролемы" HAL для одинокого пина .

1. Как говорится "Умные учатся на чужих ошибках..."
2. Никогда не говори никогда.

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

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

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

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

Поступаю также. Один в один.
Как раз для переносимости очень удобно. Чётко знаешь что этот файл придётся переписать.
Никакой неразберихи в файлах проекта у меня не возникает, так как там уже используются "осмысленные" макросы. Типа LED_ON или RG_STB. Для одного проекта (проца) может быть LED_ON единицей, для другого нулём. Это не имеет значение. Так как правится макрос, и он по макросу LED_ON загорается. (Естественно я упрощаю). Можно былобы ожидать, что этот файл большим будет, но на самом деле - совсем пустяковый. Всё сведено в одно место, сразу видны все биты и порты, видна их инициализация. Короче очень удобно.

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

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

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

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