В общем-то трудно придумать что-то радикально другое, просто у меня оно привязано конкретно к предметной области. Например, запись Qsend(u_RPL1_L); означает "послать низкий уровень на линию u_RPL1_L", которая где-то прописана, как Причем в комментарии я указал конкретный GPIO, а в макросах использован задефайненный в другом месте идентификатор для этого GPIO, так, что перекинуть это управление на другой GPIO - это исправить единственный дефайн. Запись Qrem(u_RPL1_L); выполняет действие, обратное Qsend. Запись Qtst(u_SYNC_H) возвращает состояние бита u_SYNC_H, того GPIO, который назначен принимающим сигналы состояния. Возвращает, по-простому, ноль или не ноль.

Это я к тому, что дрыгоножество GPIO не стоит таких серьезных действий, как написание могучей библиотеки на приплюснутом Си, все решается по-простому. И сразу же возражу тем, кто попытается обвинить меня в использовании "магических чисел". Когда я выбираю биты GPIO для такого дрыгоножества, у меня на втором экране открыт даташит на мой конкретный камень, я выбираю нужные ноги, глядя на всё, что там есть - не занят ли этот бит GPIO чем-то, что может мне потребоваться, как там у него с толерантностью к 5В и пр. Ну, а какой хекс-код будет у этого бита, это не вопрос даже для начинающих...

Какой к черту оверхед в макросах, пересылающих заранее определенную константу в GPIOx->BSRR ? Или мою переменную в GPIOx->ODR ?

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

ps. Понятно, что в таком простом случае оптимизатор может помочь, но С++ дает гарантию, что даже если у нас 333 пина все расчеты будут выполнены на этапе компиляции.

Дааа..., навык, на кончиках пальцев, видеть, какие вычисления будут выполнены на этапе компиляции, не легко дается. Как помочь afz?. Опять-же, разговоры про оверхед, при переходе к стандартам ООП все-же имеют под собой практический опыт некоторых авторов, я так думаю, (ну не будут же они просто обманывать, да и ради чего). Остается открытым проблема, как автор исходника умудряется "ОБМАНУТЬ" стандарты так, что все становиться просто ужасно и, хуже чем раньше (макросы) и, как с этим бороться???? (ремарка: все-же, некоторым авторам, удается обмануть стандарты ООП НЕФОРМАЛЬНО, так как формально претензий компилятор не высказывает).

P.S. Идея!!!, может строить тренд размера нативного кода во времени!!!! Пишет, пишет автор код и, вдруг, тренд показал скачок размера нативного кода, разумеется в сторону увеличения, если это делать в реальном времени, то получиться неплохой асистент в уразумении факта того, что что-то пошло не так и, автору удалось таки (НЕФОРМАЛЬНО!!!! в противоположность формально) "ОБМАНУТЬ" стандарт.

Добавлено after 39 minutes 35 seconds:
Я тоже, пока, начинающий ООП исследователь и, меня волнует эта непростая тема. В таком ключе... А вот еще вопрос, Позднее связывание (и полиморфизм) VS конечный автомат. Критерий выбора, типа, когда уже конечный автомат это мало и пора переходить к методу Позднее связывание (и полиморфизм), в том числе и в смысле границы применимости к конкретному кристаллу. Есть ли такие исследования?

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

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

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Да не надо мне помогать. Я совсем не знаю приплюснутого Си. И, скорее всего, не узнаю. Я вообще не программист. Программистом я был в 70-е - 80-е - самое начало 90-х. Минск-32, потом ЕС ЭВМ (те, что клоны Системы-360), потом Электроника-60 (клон LSI-11, микро-версия PDP-11), потом чуть-чуть, самым краем зацепил писюки, и все. С (примерно) 93-го заработать на жизнь программированием в наших широтах стало нереально, ехать куда-то за бугор - поздно, возраст уже не тот, пришлось сменить род деятельности. И только выйдя на пенсию я решил "тряхнуть стариной" и занялся программированием МК. В порядке хобби - программированием МК у нас тоже не заработаешь, нет у нас желающих оплачивать какие-либо разработки. Что можно, купим в Китае, а чего в Китае не купишь, значит оно и не нужно...

Теперь про оверхед. Вы его трактуете слишком буквально. ИМХО, необходимость написать для банального дрыгоножества GPIO такую простыню, как продемонстрировал коллега VladislavS - это не то, что оверхед, это натуральный оверкилл, несмотря на то, что оно компилируется в весьма компактный модуль. Собственно, размер двоичного кода это далеко не всегда критично, совет "не лезет - возьми камень пожирнее" никто не отменял. А вот напрягаться, чтобы сочинить ТАКОЕ - это очень сильно на любителя...

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

Ну я и говорю: на любителя. Я, помню, году, так, в 85-м тоже сильно радовался, когда заработала моя конструкция из двух или трех десятков плат с тремя-четырьмя десятками микросхем серии 155 на каждой, и все это под управлением моей же программы на Электронике-60. На асме, если что... Я все это сочинял, а коллектив лаборатории, 7-8 человек, воплощал мои фантазии в жизнь. Полгода клепали, неделю я отлаживал весь комплекс, и вот оно!!! Задача, правда, оказалась фигнёй, тем не менее, я ее решил. И мой шеф даже начал сочинять себе десерт. Я был следующим в очереди на десерт, но тут перестройка, кооперативы, да ну ее на фиг эту диссертацию, тем оно и кончилось...

Беспредметно про кайф против кайф. Вот пример, когда чел. измерил быстродействие разных кристаллов на практической задаче, очень редкий случай http://www.count-zero.ru/2018/stm32_start/. Текст длинный, ищите сразу по строке Простой бенчмарк на операции деления

Добавлено after 16 minutes 12 seconds:
P.S. А вот выдержка из https://ru.wikibooks.org "C++: В C++ позднее связывание доступно только для виртуальных методов (вызов которых становится немного медленнее). Метод, объявленный в базовом классе как виртуальный (virtual), поддерживает это свойство (но только если описания методов совпадают). Обычные, не виртуальные методы не позволяют позднее связывание, как и OP."

Я в шоке, по сравнению с http://www.count-zero.ru где все выражено циферками и эти циферки показывают разницу на порядок тут в https://ru.wikibooks.org/wiki/Объектно- ... выполнения допускают выражения "немного медленнее" НЕ ВЕРЮ. Кроме того того НЕ ВЕРЮ что "Обычные, не виртуальные методы не позволяют позднее связывание" по моему позднее связывание наступает помимо воли кодера во многих случаях.

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

А я не видел строки типа "Виртуальных методов в HAL нету, зуб даю.".

HAL вроде на С написан? Так что, я бы сказал, что там не только виртуальных, но и вообще никаких методов нет.

Понятно. Это хорошо. Но вопрос? "Метод charReceivedCB() готовит HAL к приему следующего байта." Автор которого я цитирую неуч, и charReceivedCB() процедура? Это дань моде, использовать слово МЕТОД, когда речь идет о процедуре?

Нет в С ни методов, ни процедур. Из трубопоскакаля нахватались? Есть только функции.

В C методов нет, а в кале — есть! ☺
// хехе: у меня теперь USB CDC и под андроидом работает... Тоже понял, что надо не в одну кучу все совать, а разбить на части: отдельно общее, отдельно классовое и т.п.

А тут есть нормальные компьютерные программисты? А то надо посоветоваться, а не с кем, на других форумах только посылатели в доки...

Нужно было написать на какую тему посоветоваться.

посоветоваться на тему передачи данных между приложениями Windows. но это оффтоп.

Много способов есть. Сокеты, именованные каналы (Pipe), общая память, передача сообщений через окна и т. д.

Dynamic Data Exchange (DDE) — механизм взаимодействия приложений в операционных системах Microsoft Windows и OS/2. Это?, если Вы не озабочены по самое нехочу, безопасностью. Даже OPC (OLE for Process Control) сервера прибегают к такому, например взаимодействуя с Excel таблицами. Просто, приходилось OPC и Excel дружить.

мне нужно асинхронно передавать массивы символов (строки) различной длины, причем стандартный "строковый" pchar не подходит, т.к. среди передаваемых символов 0x00 - нормальное явление. иначе говоря - передача просто блоков абстрактных байтов. главное - по возможности с минимумом накладных затрат и асинхронно, т.е. чтобы передающее приложение не ждало, пока принимающее примет и обработает. принимающего, кстати, может вообще не быть... DDE - шибко медленно, и синхронно (если я не ошибаюсь - последний раз DDE использовал лет 25 назад, еще в Win3.11)
но в данной теме все это оффтоп - если готовы помочь конкретными действиями - пишите в ЛС.