Здравствуйте!
У меня на плате полно разных сигналов управления от STM32F429. В программе нужно ими всеми манипулировать. Использовать стандартные функции HAL неудобно, при написании программы придется часто отвлекаться на плату, чтобы посмотреть, где ножки реально расположены. Даже если дефайном присвоить имя какому то выводу, непонятно на каком он порте - надо смотреть плату.

Коллега оборачивает такие вещи в функции

Но это тоже не дело. Подскажите, как вы решаете такие проблемы?

Определите понятные названия и используйте тот же HAL_GPIO_WritePin:



Коллега не умеет пользоваться определениями, можно записать так:

и потом просто вызывать:
gpioDACRESET;

Сильно доработанные напильником макросы имени Аскольда Волкова:

разумеется, определения всех ног и #include < pin_macros.h > вынесены в заголовочный файл (hardware.h).

Юзаю регистры сброса и установки, можно даже одновременно (приоритет у сброса). Никакими дополнительными макросами-шмакросами не пользуюсь, кроме тех, которыми манипулирую битами регистра. Тем более, функциями-...
Читайте Референс мануал.

Особенно если надо код с HAL ужать или надо быстро - через BRR/BSRR самое то.

Определяю ножки и порты дефайнами:

, объединяю их в массивы:


инициализацию делаю с помощью HAL:

читаю и устанавливаю через bit-banding:

У меня два подхода
1) В сложных контроллерах типа ARM использую осмысленные макросы.

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

Вся плата описана в pinout.h и например, светодиод:

#define PIN_LED_GREEN GPIOA, GPIO_Pin_8

Есть макрос gpioSet(GPIO_TypeDef* GPIOx, PIN_TYPE pin, uint8_t state);

Вызываю соотв. gpioSet(PIN_LED_GREEN, true) или gpioSet(PIN_LED_GREEN, false).

В итоге манипулирую только объектами платы (PIN_LED_GREEN), м не портами и пинами (GPIOA, GPIO_Pin_8).

Также при новой версии железа достаточно поправить только pinout.h

Два экрана.
На одном всегда открыта плата.
Схема платы специально сделана так чтобы понятен был и порт, и функция, и аттрибуты порта.

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

Не память должна подстраиваться под программу, а программа под память.

На схеме использую названия вида SIGNAL_PIN - например BUTTON_LEFT_PA1
В программе
#define BUTTON_LEFT PA1
или
#define BUTTON_LEFT_PA1 PA1
(как обычно PA0 = 0, ..., PB0 = 0x10, ..., PC0 = 0x20 и т.д)
если через макрос делается инициализация (а таких 99.9%)
то простейшие макросы переделывают PA0 в нужные маски и порты
Если runtime - то тоже не проблема переделать в порт/маску или bit-banding.
Хотя это конечно даже обсуждения не стоит.

Дергать ногами большого ума не надо. Вот что то красивое изобразить - это да.
Например нормальную (irq/dma) поддержку CAN со всеми mailbox'ами и fifo, или i2c/i2s.
С spi/uart проще конечно.

Тут без школы танцев не обойтись.

Примерно также.

#define B1_PIN (M_PORT0 | 13)
#define B2_PIN (M_PORT1 | 30)
#define B3_PIN (M_PORT0 | 12)
#define B4_PIN (M_PORT1 | 31)

#define NEW_BUZZ_PIN (M_PORT2 | 1)
(т.е. В1 это PORT0.13 etc)

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

ConfigPin2(NEW_VOL_PIN, 0x2, 0x00);
ConfigPin2(NEW_BUZZ_PIN, BRIGHTNESS_PIN_PWM_MODE, PULL_DOWN);
Включить пин на выход
SetPinOut(NEW_BUZZ_PIN);
И установить выходной уровень пина:
SetPin(SENS_ENA);
ClrPin(SENS_ENA);

https://github.com/antongus/stm32tpl - макросы Аскольда Волкова, которые творчески допилил АНТОХА.

Не знал, что можно делать такие дефайны

это позволяет одному имени PIN_LED_GREEN присвоить сразу и порт GPIOA и ножку порта GPIO_Pin_8!
очень не хотелось писать отдельные дефайны типа такого:

и потом рулить не очень удобно

а тут получается намного проще можно сделать

а зачем Вам еще и макрос и как Вы его определяете gpioSet(GPIO_TypeDef* GPIOx, PIN_TYPE pin, uint8_t state) ?

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

Всегда и на всех архитектурах использую решение на основе "макросов Аскольда" - благодаря этому моя наработанная библиотека цепляется к любому проекту и постоянно пополняется.

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

компилятор ругается на знак *
хедэр где прописан 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-а мануала на чип.

Слишком громоздко. Я при описании предполагаю, что у пина есть некоторые дефолтные опции, и в строке описания пишу только отличия от дефолта.
Например:
PINSEL(PIN_DFLASH2_CS, GPIO, 12mA);
От дефолтного отличается только задание повышенного вых. тока. Если например нужен OpenDrain, добавлю в список OD и т.п. Через запятую.
Обязательные у меня только два первых аргумента: номер/порт пина и функция мультиплексора.

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

Вы сюда локи и прерывания ещё вынесли - вполне себе... Главное, что читаемо и понятно!

Вот, а это уже интересно!
Поделитесь механизмом!
Сперва подумал, какой ацкий труд проделан по написанию каментов, а потом увидел, что и это автоматизировано - респект!

Смысл H и L в макросах не только в задании начального состояния, но и в том чтобы не думать о нём вовсе.
pin_set(PIN_NAME); pin_clr(PIN_NAME); задают состояние ноги напрямую без учёта H и L,
а pin_drive(PIN_NAME, VALUE) задаёт активное/пассивное состояние c учётом активного уровня.
Поэтому в коде программы или коде драйвера я использую только pin_drive(PIN_NAME, VALUE), чтобы не думать о активном уровне. В ваших макросах явно напрашивается третий аргумент: А,12,H или B,5,L