How to best manage seperation of concerns when developing an F'-Zephyr project

[ReggieMarr]

Hi all, I've been developing a flight software project which leverages F' for the last year and a half or so. Originally the F' code was confined to the linux based flight computer however as the support for embedded targets has grown I've been moving towards utilizing F' more widely.

Since our embedded targets use Zephyr as the RTOS I've been leveraging the work demo'd in the fprime-zephyr-reference project however it seems there's a lot of active development and so it may be an apt time for a discussion to lay out best practices and guidelines for managing the scope of ownership for the Zephyr layer vs the F' layer of a project.

IMHO part of what makes things tricky here is that Zephyr is a RTOS which also provides devicetree/Kconfig based hardware/feature configuration management and a number of other "higher-level" niceties and F' is a framework, mostly concerned with "higher-level" logic but also provides a OS and Driver adapters, and the ability to specify implementations, routing and configuration via it's cmake api, fpp and parameter support.

Most recently I've been adding in support for ADC's in the fprime-zephyr toolchain. It seems there's a choice to be made between either wrapping the ZephyrAdcDriver around a generic device struct with channel configs or leverage the channel interfaces themselves (Note examples for each here and here respectively).

TL;DR what are some standard approaches/heuristics we can apply to integrate Zephyr and F' together in a project such that each are leveraged appropriately.