Не полагайся на порядок вызовов конструкторов, инициализаторов периферии и тд - легко словить грабли в дальнейшем.

У меня все сервисы имеют три стадии инициализации:

1) Собственно сами конструкторы классов. В них я предполагаю, что класс автономен, соответственно и не обращаюсь к другим классам и ресурсам. Здесь же инициализируется периферия (естественно, два класса не могут юзать одну и ту же периферию)

2) Стадия Init - здесь уже налаживаются связи между классами (к этому моменту все необходимые объекты уже созданы)

3) Стадия Run - запускается таски, разрешаются прерывания от периферии и тд - в общем, нормальная работа приложения

объекты глобальные, соответственно создаются до main. А в main я уже вызываю init и run.

Суть в чем - не полагайся, что кто-то что-то сделал заранее

Понятно, спасибо!
Хотя не всегда объект может иметь свою собственную периферию - в случае её совместного использования невозможно ввести полную инициализацию внутрь одного класса.

Это уже следующий шаг . Тут уже соблюдаю правило - на каждую периферию - свой объект (можно назвать драйвером).
Те работа всех объектов с УАРТом идет не напрямую, а через объект - драйвер УАРТ.
Или работа с езернетом - получен кадр - сервис-драйвер езернета отправляет его всем желающим (фактически в моем Enviromnet это выглядит как broadcast пакет. Чем-то идеология на CANbus похожа )

Сам понимаешь, при таком подходе легче обходятся грабли с синхронизацией доступа к ресурсу..

Да, синхронизация - дело хитрое.
Вот, к примеру думал тут недавно над одной задачкой...

В общем, есть два канала SPI. И три объекта, "висящие" на них.
Первый - цветной ЖКИ, скорость 12 Мбит, огромные объёмы данных, способен занять канал на длительное время. Самый низкий приоритет.
Второй - диск на флешке. Скорость высокая, но пакеты небольшие - сектора по несколько сот/тысяч байт. Средний приоритет.
И третий - к примеру - декодер МП3 (или ЦАП) или другой девайс с относительно маленьким каналом, но требующий быстрой реакции на запрос.

Как их уместить на одном/двух каналах SPI, чтобы не умереть от геморроя с разделением ресурсов?

Два варианта:

A) ЖКИ транзакцию прервать никак нельзя:
SPI1 - ЦАП и FS. (в худшем случае ЦАПу придется дождаться завершения передачи текущего сектора FS, но скорость FS выская поэтому ждать не долго).
SPI2 - ЖКИ.
Приоритет ЦАПа сделать более высоким чем приоритет FS.

Б) ЖКИ транзакцию прервать без потерь можно.
SPI1 - FS
SPI2 - ЦАП и ЖКИ
обмен с ЖКИ моментально прерывается процессом обслуживающим ЦАП, и возобновляется после.



FS и ЖКИ я бы старался не цеплять на один интерфейс, во-первых чтобы скорость SPI не переключать (SPI флеш может и на 25Mhz и выше свистеть), ну и чтобы снизить нагрузку на интерфейс, т.к. потоки данных (по суммарному объему) сравнимые.

Я бы сделал так: два объекта драйвера - ClSPI_Driver<SPI0> и ClSPI_Driver<SPI1>. Следующий шаг - выяснить, необходима ли атомарность передачи больших объемов к ЖКИ (те можно ли бить данные на мелкие пакеты). Если можно передавать только здоровыми кусками (соответственно, остальные девайсы на SPI будут курить бабмбук в это время, что недопустимо), то под ЖКИ придется выделять отдельный канал SPI. А остальные девайсы повесил бы на второй SPI.

Разделение приоритетов передачи данных на одном порту:
Создаешь в драйвере очереди запросов с различными приоритетами. И драйвер, закончив очередную транзакцию начинает проверять очереди и высылать данные в порядке порядке приоритетов. Те пока не высланы данные для декодера (real-time приоритет), не трогать данные для флешки - low-prioritet для этого канала.


Те в общем, механизм был бы такой - ЖКИ единолично работает со своим SPI + канал DMA (драйвер<1>). На втором канале драйвер<2> выгребает данные из low-priority очереди (для флешки). А отдельный таск (или обработчик таймера) периодически подкидывает драйверу<2> блоки данных для декодера, который он отправляет за время не худшее, чем максимальный_объем_пакета_для_флешки / скорость_SPI + время реакции драйвера.

В общем, как-то так

Спасибо большое! Буду руководствоваться вашими советами, когда, наконец, руки до этого проекта дойдут.
Вы мне очень помогли