Единственное, шифровки тпа "PB13, 1, 1, 1, 5, 3, 3, " на меня навевают тоску. С этим надо что-то делать.

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

Зачем вы разделяете одну задачу на две? Если у меня к выводу подключен светодиод, мне его надо сначала сконфигурировать, а потом переключать.
Отдельно для светодиода, отдельно для реле, отдельно для кнопки, отдельно для каждой периферии?
Тогда к чему был пример с контроллером на ПЛИС?

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

Сравниваем: очевидный типизированный код против кода с необходимостью лезть в реализацию. Из вашего кода не очевидно за что отвечает поле buf, надо смотреть в определении типа.
Если это работает так, как я думаю, то это отличная фича языка.
Порядочно. Но вешать дисплей на несколько портов это обычно плохая идея.

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

Совершенно верно! Причём вы пишете код, чтобы ему можно было просто в заголовочном файле типа main.hpp указать параметром шаблона куда он подключен и всё. Да какая разница диоду на какой контроллер он подключен? Ему надо знать как поставить "0" и "1" на той ноге что ему указали и задать соответствие между "0/1" и "вкл/выкл".

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

Где вы видели? Я показывал свой код? По фрагментам судите?

"Мочало, мочало, начинай сначала". Много раз показал, что быстрее. От нескольких тактов на простой операции до десятков раз на сложных.

В том то и дело, что вы не упарываетесь и получаете менее оптимальный код. И я не упарываюсь тоже, но за меня это делает компилятор, неустанно, в каждом проекте, сурово и беспощадно.

Это на какой такой планете?

Может стоит глаза разуть?

Чёрное это белое, война это мир. Выведи не пойми что не пойми откуда в вашем случае. Против чёткого "выведи все элементы буфера", при этом тип элемента будет автоматически учтён и правильно выведен, именно так как в буфере и хранится. Как можно так шиворот на выворот реальность переворачивать?

А из вашего аж прям так очевидно...

Именно так и работает. А ещё, это не влечёт за собой вызова кучи функций. После того как всё "пробросится" происходит генерирование кода с полной оптимизацией всего и вся. Будет просто быстрый оптимальный код. Бывает, что он больше по размеру из-за сильного инлайна, но зато быстрее работает.


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

Графическая утилита с выбором ног и режимов и генерация готового кода чисто конкретно под этот выбор. Я серьезно, не шучу. В CubeMX красивая и удобная графическая часть. Почему бы не запилить подобную графическую утилиту? Вот это будет класс по всем направлениям. А то портянки текста, куча потраченного впустую времени. Единственный плюс - изучил кодописательство на продвинутом С++. А в остальном - ааа, фихня, оверинжениринг и трата времени. По-другому делать нада! Нужно оформлять в утилиту удобного графического представления, как это сделано в CuveMX. И что бы вы там не говорили, сколько бы портянок не писали, но это всего лишь полумера, на узкого любителя портянок и ради самолюбования.

" ! Даешь парсер портянок hal'a !"
и пусть выплевывает регистры со значениями

HAL - это Hardware Application Layer - очень правильная идеология абстракции уровней программного кода. А самый правильный инструмент конфигурирования - диалоговый, с кодогенерацией компактного кода без излишней лапши.

VladislavS, помнится, у меня губа отвисла, а у этого еще и слюна потекла.
У avr нет отдельной графической утилиты, пользуемся вспомогательными средствами, такими как, например cvavr.
НовыйДень, вот возьми да сделай доброе дело, изобрети графическую утилиту, глядишь другие люди большое спасибо тебе скажут.

Нет, HAL - это дополнительный лишний слой абстракции над cmsis. Он не может 100% верно задать последовательность действий, не может простым способом показать ключевые точки управления, не имеет нативного деления на слои. Всё что он может - предоставить полный контроль над всей имеющейся информацией.
А мне не надо весь контроль, и не нужна вся информация. Этого всего банально много, слишком много.
Мне нужно готовое решение, с ограниченной зоной видимости, и явным указанием управляющих функций. Но в готовом виде ничего похожего нет. По этому приходится постоянно возить за собой свою маленькую тележку, с прицепом из 13-ти вагончиков кода.

Золотые слова! Только делать это надо на С++ с шаблонами, хорошие примеры этого были у VladislavS, или ПЛК. Других вариантов нет. Только в этих случаях можно получить максимально эффективный по размеру и/или скорости код.

Ещё раз перечитайте историю создания С. По-сути, это высокоуровневый ассемблер, посему все оптимизации только за счёт опыта и старания того, кто программирует. С++ со всей его заумью последних версий как раз и создан для того, чтобы программист мог описать, как делать всю низкоуровневую оптимизацию, чтобы компилятор построил оптимальный код.

Добавлено after 5 minutes 44 seconds:
COKPOWEHEU, знаешь, чё самое прикольное? Это когда берёшь портянку от VladislavS, целый вечер читаешь Страуструпа, чтобы понять написанное в этой портянке, а потом в дизассемблере видишь, что эта портянка превратилась в полдюжины команд проца.

tonyk, я говорю о том, что самый правильный вариант - это скрытие портянок (на любом языке, хоть на пайтоне) и выдачу сгенерированного компактного куска кода.
VladislavS наваял конечно много монструозных портянок с глубоким погружением и оверинженирингом, чем очень и гордится. Но времена не стоят на месте, сейчас это уже не актуально, он опоздал. Для теоретиков программирования - эта монструозность сойдет, чисто для погружения в возможности С++. Но для практиков программирования сия тряхомудия является просто атавизмом и зря потерянным временем. Сейчас не 2012 год, а 2022. И ныне в тренде наглядные, визуальные методы, а не портянки текста с проприетарным наполнением. Отгадайте секрет бешеной популярности Cube MX. Секрет в том, что этот инструмент попал в нужное русло и соответствует духу времени, посему не требует той навязчивости и убеждений, как у портянок VladislavS. Вот и всё. Я ж говорю - вот эти его портянки закрыть бы в диалоговую графическую среду - и был бы совсем другой коленкор.

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

Слюна до пола.

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

VladislavS, ну так ты ж усердно продвигаешь тут свою кодописанину, а потом вдруг обижаешься, что её обсуждают Критику то надо уметь принимать, а не только расхваливать ЧСВ.
И правильно - лучше никому не показыавай свою писянину, а то засмеют за оверинжениринг, когда узнают, что тонны портянок всего лишь конфигят порты и кой-чо помелочи еще. Это на несведущих только может произвести вау-эффект. А практикующие программисты скажут: "И это всё, что могут эти портянки? А знаешь, завтра к нам приезжают (например) PIC32 с совершенно другой структурой. У тебя есть срок до обеда, чтобы переписать свою тряхомудию на новые МК".
На практике то оно выглядит всё совершенно иначе, чем в теории. На практике - диалоговый конфигуратор вместо портянок оверинжениринга. Такой вот раскладец. И можно чо угодно и как угодно расхваливать, но портянки - для собственного ЧСВ ("а вот как я умею!), а для практической работы - закрытый конфигуратор, герерирующий готовый компактный код по месту.

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

Спойлер

Ох уж эти вантузоиды! Вот только дай им мышей потыкать!
Прискорбно, что дегенератов в мире так много…

А самое ужасное — то, что большинство этих дегенератов работают. И на работе занимаются этим тряхомудием. А потом орут: почему это в России все так через жопу? А в зеркало смотреться не пробовали??? Если б не было 99% населения дебилов, то и страна в говне бы не сидела!

Берем еще раз несколько строк инициализации дисплея:

Здесь можно указать любые пины и все максимально оптимизируется т.к. среди прочего этот код юзает либу портов предоставляющую соответствующий функционал. Если делать конфигуратор он ведь может сгенерить такой-же компактный код? Конечно может, более того это еще и упростит написание самого конфигуратора. С другой стороны он может нагенерить плохо читаемые портянки настолько же эффективного кода под конкретные пины или нечто менее громоздкое, но и настолько же менее эффективное. Точно лучше получится? Ты за портянки или против? Хороший конфигуратор должен опираться на качественные библиотеки которые полезны и сами по себе, они могут быть достаточно сложными и изощренными, но зато в итоге не получится еще один Куб. Нужен нам второй Куб?

Ну так любую задачу можно разбить на подзадачи.
И сколько вариантов периферии вы реализовали? Отдельно светодиод. Что еще?
Нет, меня удивило зачем вы такой приме рпривели в обсуждении настройки на push-pull. У вас часто возникает задача генерировать такие контроллеры и настраивать именно урезанные пины?

Да, по фрагментам. Даже ваши фрагменты занимают раза в три больше места, чем аналогичный макрос.
Выигрыш в пару тактов у вас только там, где вы заморочились с ручной оптимизацией (вроде байтового доступа к регистрам).
Зачем вы врете? Компилятор не имеет права разивать 32-битный регистр на байты, это вы делали вручную.
На Земле. Это третья планета солнечной системы.
И что, общие соображения внезапно станут фактами?
Не знаю зачем вы пытаетесь вывернуть реальность.
"выведи все элементы буфера независимо от типа" - но нужно не элементы буфера, а байты. Тот же USB не элементами буфера неизвестных типов оперирует, а байтами.
Конечно, он же не завязан на внутреннее устройство переменной. Хоть int туда подставить, хоть строку - все будет работать очевидно и предсказуемо.
Хорошо, но какое это имеет отношение к разбиению линии данных по портам?
Изменить способ обмена через define ничуть не сложнее.
...идиотов.
Код должен быть доступен для чтения и редактирования без специнструментов. Тот ужас, что генерирует Куб или cvavr, для чтения непригоден. Спецутилиты устаревают и становятся просто недоступны.
Представьте, что такой же кубом ушибленный написал свой кодогенератор на каком-нибудь quickBasic, который подставляет прямо номера регистров и значения в десятичном виде. Допустим даже, что он добросовестный и вместе с каждым проектом прикладывает исходники своего кодогенератора. Вот только так получилось, что он работает исключительно под MSDOS какой-то замшелой версии и с конкретным аппаратным багом.
А вас заинтересовал его проект и вы хотите им воспользоваться. Как вы будете это делать?
А теперь представьте, что кодогенератор писали не менее добросовестные программисты на каком-то предприятии десяток лет назад под какую-нибудь win98. Вот только исходники за давностью лет потерялись. Так что эта штука работает только под win98, генерирует код в стиле, принятом именно у них и заточен под те три контроллера, с которыми они работаели.
Или исходники не то что утеряны со временем, а изначально писались кем-то недобросовестным, кто исходников не просто не публиковал, но и старательно обфусцировал: вот вам образ для Mac, вот скомпилированные объектники библиотек - пользуйтесь.
Или, как сейчас модно, онлайн-конфигурялка. А сайт внезапно забанили.
Не говоря о том, что бывает, когда подобный "код" выкладывают на форумах. У окружающих ведь вашего конфигуратора, естественно, нет - есть только портянка с кучей невразумительных функций и магических чиселок без форматирования и комментариев.

Промышленное изделие с чипом stm32f, и очень красивой разводкой почти в одном слое - это плод любви того самого дизайнера, который так видит.
Красиво, это когда все ноги с одной линии контактов - без переходов уходят на чип с параллельным портом, одной красивой полосой проводников.
Да, красиво, да работает - но в 100 раз медленнее чем могло-бы работать.
А это означает что можно было взять чип в 100 раз слабее и дешевле. Мысль понятна?

Ну так зачем делать конфигуратор, который будет генерить плохой код? Хороший конфигуратор выдаст код длиной в несколько строчек, в которых будет чисто конкретно только то, что нужно.
Некоторые из вас никак не могут понять, что все эти длинные портянки, которые тут показывал VladislavS, прячутся в недра конфигуратора (они даже могут быть написаны на любом другом языке, хоть на Питоне), а на выходе в файле исходника получается короткая выжимка, всё чисто по месту. И верх красоты - конфиг нужных пинов в одном месте за раз.
Вот это - действительно дело. А не то, что вы там насочиняли портянок и гордитесь тем, кто больше лишнего текста напишет. Упражняться в кодописательстве - прекрасно. Но для практикующего программиста этот случай неинтересен. Вау-эффект можно произвести только на несведующего программиста. А любой профессионал скажет вам: "И это всё, чего ты сделал за год? Тьху ты, блин. Ты нам не подходишь."

Ну и для несведущих погромистов еще раз напоминаю: HAL - Hardware Abstraction Level. А Cube - это приложение-конфигуратор от STMicroelectronics. Кому то оно нравится, кому-то нет. Но HAL - это Hardware Abstraction Level, а не название продукта. И не путайте понятие и название.