Arlleex

Поверьте, если кто-то с этим столкнется, это просто снесут и заново напишут)

Ды хоспаде, не используйте и все. Да, малина может отсеивать, я же не знаю что там за ПО.

Прям на разъеме пины подписаны, SCL/SDA. Делается такое с целью подконтрольного выпуска серии камерных модулей. Прописали туда серийник, запаролили, а с хоста отсеиваете потом чужих.

А как в свиче не может быть self filtering? Почти в каждом первом он в наличии.

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

Про какую обратную совместимость вы говорите? Еще раз - попробуйте struct A { int a, b, c, d; }; int main() { A a = { .a = 10, .b = 20, .c = 30, .d = 40 }; } в C++20 - ок, работает. Тащим кучу легаси кода на C++11 компилятор и получаем ошибки компиляции. Вот она обратная недосовместимость. Обратная совместимость в плюсах - это всегда минное поле - вроде ходишь по знакомым местам, а прилететь может с любой стороны.

Это одно... Но C++ "развиваются" так, что нет уверенности, что код не то что будет выглядеть современным, а вообще компилироваться в ближайшем будущем при переходе на свежую версию. Посмотрите, например, чего они с назначенной инициализацией делали - изначально она была, начиная с 11 версии - она выпилена, в 20 снова стала доступна. Ну и зачем оно такое?

Какая разница, обложить функцию InitGPIO() плюсовыми фишками всяких там шаблонных штук, которые при смене МК придется переписать, или переписать сам InitGPIO() напрямую? В текущем проекте мне было совершенно некогда заниматься созерцанием, поэтому я воспользовался своими отлаженными макросами для модификации битовых полей в регистрах UPD_BIT(GPIOA->PUPDR, RST(GPIO_PUPDR_PUPD12_Msk | GPIO_PUPDR_PUPD11_Msk), SET(0x1 * (GPIO_PUPDR_PUPD12_0 | GPIO_PUPDR_PUPD11_0)), INV(0)); UPD_BIT(GPIOA->AFR[1], RST(GPIO_AFRH_AFSEL12_Msk | GPIO_AFRH_AFSEL11_Msk), SET(0x9 * (GPIO_AFRH_AFSEL12_0 | GPIO_AFRH_AFSEL11_0)), INV(0)); UPD_BIT(GPIOA->MODER, RST(GPIO_MODER_MODER12_Msk | GPIO_MODER_MODER11_Msk), SET(0x2 * (GPIO_MODER_MODER12_0 | GPIO_MODER_MODER11_0)), INV(0)); UPD_BIT(GPIOA->OTYPER, RST(GPIO_OTYPER_OT12_Msk), SET(0), INV(0)); UPD_BIT(GPIOA->OSPEEDR, RST(GPIO_OSPEEDR_OSPEED12_Msk), SET(0x2 * GPIO_OSPEEDR_OSPEED12_0), INV(0)); Читаемо? Ну, мне понятно - хотя и тут можно все эти чиселки и гвоздеприбитые определения вытащить в один хедер, где определить пины в виде #define CAN_RX A, 10 и т.д. Не охота.

Ну а зачем пытаться вникать в трехэтажную наскальную живопись плюсов, которая работает в C++17, но не работает в 11, но частично работает в 20, а в следующих версиях вовсе сделали улучшение и теперь все предыдущие способы расцениваются гурами как говнокод?

И переходим на другой контроллер со своими тараканами и хитрожопыми регистрами, допускающими какой-то уникальный способ инициализации всяких пинов через какой-то хитрый регистр, и вся эти мутотень в виде отлаженных трехэтажных шаблонов летит в помойку... и все по новой. От плюсов в МК до сих пор использую лишь пространства имен и иногда шаблоны структур - но не в драйверах железа, а на чуть более высоком уровне. Там в них смысла больше. А работа с регистрами сводится к тому, чтобы не ошибиться записать нужное число в нужное битовое поле регистра. Поэтому без всяких плюсов я себе наклепал горстку упрощающих жизнь макросов, обычных Сишных. Зато сразу понятно, что они делают, и от перехода на новый стандарт хоть плюсов, хоть Си, не зудит в одном месте - будет ли работать очередная хитрая конструкция в виде 100500 шаблонов или нет.

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

Ну, не знаю. Один раз написал и отладил драйвер всех внешних лампочек и кнопок, и наружу выдал API их управления - дальше, на высоком уровне, можно уже что угодно делать. Даже вчитываться не буду)

Обоснование, скорее, в том, что нет оснований полагать иного🙂

Будет вызов A. А что тут обосновывать? Есть более интересные примеры...

Зато честно)) бывает, шо уж. Скорее всего, увидели бы, что счетчики ошибок передачи долетели до 255 и контроллер ушел в состояние BUS OFF.