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_at_gmail.com> wrote:
> On Thu, Mar 11, 2021 at 6:51 PM Davis Hoover <dhoover_at_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.
>>
>> https://gitlab.com/opencpi/opencpi/-/blob/develop/runtime/drc/ad9361/src/RadioCtrlrNoOSTuneResamp.cc#L698
>>
>> https://gitlab.com/opencpi/opencpi/-/blob/develop/runtime/drc/ad9361/src/RadioCtrlrNoOSTuneResamp.cc#L710
>>
>>
> 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
>
Received on Fri Mar 12 2021 - 03:51:53 CST