Потому что 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 счетчик для пина должен принципиально отличаться от таково же для модема ?

А если проц поменялся? У меня это просто:
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обственно, что-то похожее и показывают в разговорах о передаче по ссылке и по значению. Ошибки, на мой взгляд, одного уровня, нормальный человек их может сделать только в начале обучения либо поздно вечером в пылу спора

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

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

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