Почему то не получается сделать макрос

компилятор ругается на знак *
хедэр где прописан GPIO_TypeDef подключен

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

Совсем запутался...а как правильно передать созданный дефайн в макрос?

Жесть какая.... Откройте учебник по си! Макрос - это не функция: #define SET(GPIOx, GPIO_Pin) ...

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


Именно.



У меня единый gpio_utils.c для STM8/STM32, а в нем уже реализации (макросы) под каждый МК. Чтобы не вспоминать каждый раз у кого там
GPIO_SetBits, а у кого GPIO_WriteHigh. Ну и появлется возможность передать в качестве значения пина булевое выражение, а не делать if

Извините, я макросами никогда не пользовался, просто у turnon было написано gpioSet(GPIO_TypeDef* GPIOx, PIN_TYPE pin, uint8_t state), поэтому я тоже начал типы вставлять.
В общем, сделал так

Вот теперь уже лучше. У меня в проектах примерно также, только пин я определяю короче:
#define PIN_SSP1_SCLK F, 4
#define PIN_SSP1_TX 1, 4
#define PIN_SSP1_RX 1, 3
#define PIN_LCD_LED 6, 9
Если нужно, потом к ним можно приклеить необходимые префиксы/суффиксы (типа GPIO): GPIO##port внутри макросов
Подобно:
#define SET_(port, pin) GPIO##port, GPIO_PIN_##pin
#define SET(port_pin) SET_(port_pin)
И не пользуюсь никакими HAL-ами, а прямо внутри этих макросов обращаюсь к регистрам GPIO.

И зря. Вы лишаете себя таких благ как:
Как видите, совсем не надо запариваться ни о инициализации, но о активном уровне.

Не понял чего именно я лишаюсь.... Инициализация пинов у меня делается примерно так:

В списке аргументов макросов PINSEL и PinSel1 - опции доступные для данного пина (подтяжка: PU или PD; фильтр: SL; макс.ток: 2ma, 4ma, 8ma, 12ma, 18ma... и т.п.).
Первый аргумент в списке - имя пина (заданное define), второй - функция (GPIO или одна из спец.функций доступных на этом пине), далее - опциональный список опций пина произвольной длины.
PinSel1 и PinSelN конфигурят как опции пина(-ов) типа pullup, pulldown, opendrain и т.п., так и программируют мультиплексор пинов на нужную функцию.
Здесь я привёл примеры для Tiva, но в других проектах на других МК у меня организовано подобным образом, только список опций пинов другой.

И есть кучка макросов типа Pset(PIN_...), Pclr(PIN_...), Pval(PIN_...), Pin(PIN_...), Pout(PIN_...) и т.п.
Такие имена макросов у меня тоже одинаковые для разных проектов на разных МК, только реализация внутри разная, зависящая от периферии.

И совсем не запариваюсь о инициализации и т.п.
При добавлении нового пина просто добавляю ещё одну запись с описанием необходимых его опций. И очень легко переназначать пины, менять назначение портов (UART, SPI, ...).

Вот готовая реализация на макросах. Там описание + примеры для F0, F1, F4 и L1.

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

Есть драйвер чего бы то ни было и именно он в своей функции driver_init() вызывает pin_init(PIN_NAME) для своих линий ввода-вывода без каких либо дополнительных аргументов и дёргает ногами на своё усмотрение. Смысл абстракции именно в этом!

А у вас куча совершенно лишних буков там, где их быть не должно.
ГОРАЗДО разумнее в одной строке задефайнить всё сразу: и номер пина, и порт, и активный уровень, и все режимы работы порта, и ремапы, а не размазывать сопли по коду.

Пример для STM32F37x

Вы лишаетесь прозрачности и удобства описания таргета: одна нога - одна строка и НИКАКИХ завязок более.
Даже если вы, например, поставили инвертор в цепи где его в прошлой плате не было, то НИЧЕГО в коде менять не надо.
Заметьте, именно так выходит полностью абстрагироваться от таргета и в смысле схемотехники платы, и в смысле типа MCU: хотите AVR, хотите STM32, хотите чёрта в ступе. НИ один высокоуровневый драйвер патчить не придётся вовсе. Создал новое описание таргета lowlevel333.h и в путь, не меняя в проекте ни одной строчки.
Предвосхищая ваши попытки сказать, что у меня, мол, тоже только один файл описания... Тоже, да не совсем - вы решили лишь половину задачи и ту не самым красивым способом. У каждого своё чувство прекрасного и я не хочу вас обидеть, но мне нередко смешно и грустно читать ваши безапелляционные посты, в которых, надо признать, часто много правильных мыслей...

Не интересно смотреть. Своё уже давно написано. Но на первый взгляд не понравилась нотация макросов. Вы не учитываете некоторые весьма оправданные рекомендации, как то: если поведение макроса неотличимо от поведения функции, этот макрос должен быть назван с использованием строчных, а не ЗАГЛАВНЫХ букв, от которых рябит в глазах. Плюс выбраны не самые удачные имена HIGH, LOW - H,L достаточно на 100%. PIN_CONFIGURATION - очуметь как много букв!!! pin_init, pin_setup, pin_cfg - это синонимы не скрывающие смысла происходящего. В этом ключе, да и других направлениях есть куда расти... Чтобы стать профи никогда не стоит пренебрегать чтением профессиональной литературы - там зачастую есть чему поучиться. А про то, как правильно выбирать названия переменным и функциям, вообще в букварях пишут)))

2ALL: перечитайте название этого топика ещё раз, прежде чем сюда написать.

У меня как раз все режимы пина одной строкой и задаются. Но его номер и номер порта на котором он находится (или просто номер ноги корпуса) задаётся отдельно. Мне так удобнее, так как у нас обычно разрабатывается не одно устройство, а линейка устройств с подобным функционалом и, соответственно, с такими-же почти ногами, но с разной схемой, так что в одном из устройств линейки этот вывод находится на одной ноге, а в другом - на другой. И файлы работы с пинами - общие, свой только для каждого конкретного устройства, файл описания распределения пинов по реальным ногам чипа.
Так что строки режимов для PIN_... - общие для всей линейки в одном файле, а вот файлы с присвоением PIN_.... номеров ног - разные.

А где у меня лишние буквы? Вроде всё по минимуму...

ИМХО одна строка всегда яснее чем две. Но идея с разделением ясна и она действительно м.б. оправдана в случае действительно огромного кол-ва вариантов железа ИМЕННО c прыгающими ногами. Мне сложно такое вообразить (сегодня реле PORTA,2 завтра PORTB,3, а в пятницу первый отряд лагеря меняется бельём со вторым). У меня за более чем 15-ти летнюю поддержку разных линеек приборов КИП и ПЛК наблюдается максимум 6-ой вариант железа у одного из них. У вас что, это чаще происходит? Вы в какой сфере варитесь? И что же вы про задание активного уровня не говорите ничего - у вас он тоже в конфиг режимов задвинут и как же ж он работает?))) ИМХО у вас этого функционала просто нет.
Ладно... Душевно обсосали темку. Спокойной ночи!

Блин - написал такое развёрнутое сообщение с описанием, и грёбаный сайт глюканул и всё потерялось ((((((((((((((((
Заново писать неохота. Но вкратце: новые вариации железа у нас появляются не только во время поддержки устройства, а уже при старте разработки: сразу запускается линейка устройств с примерно одинаковым ПО, но разных схемотехнически.
Например: счётчик э/энергии 1-фазный прямого включения, счётчик э/энергии 3-фазный прямого включения, счётчик э/энергии 3-фазный трансформаторный, контроллер сбора данных, ....
У каждого из этих устройств линейки отдельное ПО, но большая часть файлов этих отдельных проектов - одинакова (просто копируется из проекта в проект). И у каждого есть файл описания номеров пинов, а вот уже работа с этими пинами может находиться в общих файлах драйверов, которые одинаковые для всех этих проектов.
Эти устройства в линейке могут быть построены даже на разных МК (в прошлой линейке использовались МК: LPC1758, LPC1778, а у них некоторая периферия совершенно разная (например - мультиплексор пинов)). Плюс ещё: у каждого из устройств линейки может быть несколько исполнений (в том числе и новых исполнений, появляющихся уже во время жизни устройства, если заказчик вдруг захотел другой набор аппаратных опций). Опции например такие: RS-485 (или несколько), ZigBee, GSM, Ethernet, PLC, RF, реле отключения фаз, осциллографирование, резервное питание и др. Разные исполнения - разная комбинация этих аппаратных опций.
И количество файлов в проектах ПО очень большое. Так что и стараемся при добавлении нового функционала или при смене ног, минимально трогать готовые файлы например с драйверами устройств.
Работаю я в сфере разработки устройств для э/энергетики: счётчики э/энергии, контроллеры присоединений, ...
Сейчас новая линейка в разработке на базе МК Tiva (от TI), но тоже - разные устройства в линейке построены на разных МК Tiva, плюс имеют - разный набор периферии внутри: один или два чипа флешь, (одного или другого типа), разные чипы FRAM, наличие или отсутствие других чипов (в зависимости от необходимого функционала). Места на платах очень мало, да надо ещё подешевле. Так что есть более дешёвые устройства в линейке, есть дороже. На более дешёвых может и плата меньше слоёв иметь. К тому же - есть ограничения по размеру платы, ограничения накладываемые необходимостью гальванической развязки и т.п. Это приводит к тому, что распределение пинов получается разным (по портам и номерам), но драйвера периферии должны быть по возможности одинаковыми.
Вот поэтому у нас для каждого устройства в линейке свой файл распределения пинов по номерам портов и разрядов, а инит их - общие файлы.

Не понял вопрос про задание активного уровня. При инициализации пина ему задаётся некое начальное значение (если это GPIO-пин), а потом меняется драйвером по его алгоритму. Есть у меня макросы установки/сброса/... текущего состояния GPIO-пина. Описывал их выше.

И этого слишком мало!

Если описывать то всё, включая все альтернативные функции.
Вот так:


Тут немного искажено , поскольку включился автоматический перенос строк, но принцип понять можно.
И эта таблица генерится прямо из PDF-а мануала на чип.