При чём тут винегрет? Да, есть драйвер I2C_GPIO, он сам себя
инициализирует, если до того не вызывали. Да, оно под капотом и
кишки наружу не торчат. Но функция включения светодиода в
приложении вызывает ручками вписанную (назначенную) функцию от
этого драйвера или от CPU_GPIO (драйвер, как ни странно, тоже
бывает нужен). И она действительно чихать хотела как оно
реализовано. В CPU_GPIO может быть bit banding, работа с Set/Reset
регистрами, может быть чтение-модификация запись с критическими секциями, в то же время в I2C расширителях может отсутствовать чтение регитра OUT, и заводятся буферки для кэширования, да и сам вывод буферков может быть по расписанию. Там ваши изыскания насчет расово-правильного построения битиков в исполнении компилятора всего-лишь очень далекое от приложения развлечение. Иногда полезно при отладке без приложения - когда класс не знает о функциональном назначении его членов в приложении.
Мне это напомнило эволюцию кремния и утилит для окучивания GPIO. Когда-то использовал C51 от Cygnal (Silabs который нонче) и там был мультиплексор альтернативных функций, но с особым последовательным порядком подключений, ну и вдобавок все подтяжки включались одним битом. Без утилиты настройки GPIO там было совсем грустно. После такого GPIO в M4, которые не требуют всё в одну посуду, явно гораздо ближе к модульному построению кода сверху вниз
Vit (23.06.2024 12:44, просмотров: 216) ответил VladislavS. на Всегда есть особенности реалищации, но не надо делать из этого
винегрет. Светодиод не должен заниматься проверкой инициализации
порта. Это дело самого порта. Если у вас такой хитрый порт, то и
наворачивайте его логику. Оставьте светодиоду светодидово. Так код
будет проше и понятней.