All but 3 lines of the 39 results refer to older or lower-level RCC proxies that overlap in functionality with the DRC (which should probably be consolidated...).
 
Here is a DRC briefing - slide 18 might provide a little more context (and exemplify the degree of abstraction!)
https://opencpi.gitlab.io/releases/latest/docs/briefings/Briefing_14_Digital_Radio_Controller.pdf

Abstraction does contribute to complexity here, but it also enables the interoperability afforded by DRC. DRC solves two essential problems: 1) abstraction and portability of radio command/control, and 2) intelligent erroring and prevention of radio misconfiguration. No. 2 is a hard problem, especially in the AD9361 case (whack-a-mole issues where changing one setting changes another setting) - you're solving that hard problem now so application developers down the road don't have to know a thing about AD9361. I'm not aware of any other framework that solves problem 2.

There could certainly be improvements. As for documentation, much effort was initially put into Doxygen comments (e.g. https://gitlab.com/opencpi/opencpi/-/blob/develop/runtime/drc/ad9361/include/RadioCtrlrNoOSTuneResamp.hh). Please feel free to offer specific recommendations or alternatives - documentation or otherwise.

On Thu, Mar 11, 2021 at 7:09 PM Brian Padalino <bpadalino@gmail.com> wrote:
On Thu, Mar 11, 2021 at 6:51 PM Davis Hoover <dhoover@geontech.com> wrote:
Just 2 cents which may help or may just tell you what you already know - a git grep in the core framework for tx_rf_port may be helpful. The following two lines are one example of a place mapping is done. Running OpenCPI w/ gbd and breaking on lines such as those below might help tracing things.


I grepped through the code and found in that RadioCtrlrNoOSTuneResamp.cc file where the initial PHY params were set to 1 instead of 0 (strange, but OK), but I don't see how just grepping for tx_rf_port got you to knowing where to look.  For example, when I do "git grep tx_rf_port | wc -l" I get 39 results - 1 of which is the line that actually gives me a hint to look at getRfOutput().

Doing "git grep getRfOutput" gives me 4 lines in implementations with no comments on what the function actually does.

I'm all for suggestions and hints, but other than this mailing list, these new platform devices just seem like a lot of magic incantations and a ton of abstraction.

Brian