#include - оптимальное использование директивы

[Исбанни]

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

А как же в ней управлять инициализацией интерфейсов, если устройств на них чуть больше, чем одно?

Так в один и тот же момент времени через один интерфейс вы обращаетесь не более, чем к одному устройству на интерфейсе.
Например, интерфейс I2C. Все устройства, сидящие на одной такой шине, имеют общие настройки - частота (100k, 400k, 1М), ширина адреса.
U(S)ART - тоже одинаковый тип, одинаковая скорость, одинаковые настройки стоп-битов.
SPI - желательно тоже иметь одинаковую скорость ширину для всех устройств на общей шине.

Для инита хардвара я обычно выделяю связанную пару файлов hardware_init.c, hardware_init.h, и там и прописываю вызовы функций инициализаций драйверов.
Для случая с общими интерфейсами можно вызывать один раз функцию с обобщенными настройками.
Пример файла hardware_init.c:

#include "../Drivers/EDP154_Drv/interface_drv.h" // драйвер интерфейса e-ink дисплея
#include "../Drivers/I2C_drv.h" // драйвер I2C

void NormalHardwareStart(void)
{
    EPD154_Interface_Init();  // инит интерфейса дисплея
    I2C_Init();    // инит I2C
}

...и вызов ф-ции NormalHardwareStart() из main в самом начале прекрасно настраивает периферию МК на работу.

Касательно энергосбережения, вот потому ф-ция и называется NormalHardwareStart, потому что используется для запуска в нормальном рабочем режиме. Можете прописать функцию AbridgedHardwareStart c сокращенным запуском периферии МК при работе в энергосберегающем режиме. Например, в ней настраивается только UART для работы в режиме ожидания приема команды. Как только нужная команда принята, вызывается NormalHardwareStart.
Режимы энергосбережения зависят от конкретного микроконтроллера. Я ориентируюсь на STM32.

[Easyrider83]

У меня не много по-другому сделано. Я возвращаю указатель на void. Функция создает драйвер и возвращает указатель. Внутри драйвера есть функции вызова. Если драйвер не создан, возвращается ноль или функции возвращают код ошибки.

[parovoZZ]

Для инита хардвара я обычно выделяю связанную пару файлов hardware_init.c, hardware_init.h, и там и прописываю вызовы функций инициализаций драйверов.

Очень хорошая идея.

[parovoZZ]

Завидная древовидность, типа самотестирования. На выходе - ноль, ноль, ноль, ноль и по телетайпу "МК не обнаружен или живёт своей жизнью и просит его не беспокоить".

бугага

[parovoZZ]

вызов функции уже не обращение к подпрограмме?

Раз уж здесь собрались кандидаты наук, то здесь спрошу.

Вызов функции внутри обработчика прерывания не есть выход из обработчика прерывания?

[CERGEI1982]

Вызов функции внутри обработчика прерывания не есть выход из обработчика прерывания?

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

[mike-y-k]

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

[Исбанни]

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

[Исбанни]

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

[eddy]

Вызов функции внутри обработчика прерывания не есть выход из обработчика прерывания?

Вот как сбросили флаг прерывания, так считай и вышли. А уж где это произошло — все равно. И тоже присоединяюсь к тем, кто считает, что обработчик прерывания должен занимать как можно меньше времени. Циклов 10-20 — и хватит!

сильно снижает время реакции системы на событие

Смотря что за событие. В подавляющем большинстве случаев достаточно в прерывании выставить флаг, а в основном цикле его обработать. Если вам с микросекундной точностью надо время внешнего прерывания засекать, то можно просто выставить глобальную переменную — время срабатывания, а затем обработать. Хотя, я и сам — тот еще рукожоп: для системы старт-финиш время по PPS с GPS корректировал внутри прерывания, что не очень-то хорошо, учитывая наличие еще уймы прерываний (хоть от того же USB).