Brian,

Feedback:

Thanks for taking the time to provide feedback - I can't speak to how much your comments may be considered, but you make comparisons worth considering. I'll let Kulp chime in here.

Doc:

Here's all the documentation that I know about. I know it's a lot, but reading it all would certainly help anyone tasked with DRC development.

(latest, high-level context) https://opencpi.gitlab.io/releases/latest/docs/briefings/Briefing_14_Digital_Radio_Controller.pdf
(a little history and overall context) https://gitlab.com/opencpi/opencpi/-/wikis/Digital-Radio-Controller

(perhaps outdated, discusses Doxygen, good block diagrams w/ complex mixer, etc) https://opencpi.gitlab.io/releases/latest/docs/assets/Dig_Radio_Ctrlr_FMCOMMS_2_3.pdf

(perhaps outdated, gives application context of DRC, discusses hardware portability) https://opencpi.gitlab.io/releases/latest/docs/assets/FSK_Dig_Radio_Ctrlr.pdf

(Doxygen, which is somewhat incomplete, is sprinkled throughout, every @brief exemplifies Doxygen comments, do a "git grep brief" to find all Doxygen in core framework) https://gitlab.com/opencpi/opencpi/-/blob/develop/runtime/drc/ad9361/include/RadioCtrlrNoOSTuneResamp.hh

ADI library:
I didn't intend to imply that the AD9361-related DRCs do anything besides take the good work ADI has done on their library, wrap it, and add functionality that provides improvements towards OpenCPI's core mission. While the DRC implementation has its faults (does not expose all no-os functions (yet), untested multi-AD9361 capability, etc), the interfaces and their corresponding functionality afford what is promised by the points I made in 2). For example, ADI's library absolutely does not tell you when changing the sample rate on one channel changes the sample rate on another, which can be a problem for an app developer not intimately familiar w/ the AD9361. DRC not only tells you in the logs, but prevents you from changing an existing setting which is locked. Such functionality is necessary to de-couple application behavior from that of the radio hardware, which aligns with the core portability principles of OpenCPI. Another minor point - ADI has different APIs for different radios (link below), and OpenCPI benefits from providing a higher layer of abstraction, thus allowing application portability across radios via a single, high-level API (namely, the DRC component spec).
AD9361: https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz/software/baremetal
ADRV9009: https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/talise/talise_radioctrl.h

Best,

- Davis

On Mar 14, 2021, at 8:07 PM, Brian Padalino <bpadalino@gmail.com> wrote:

Hey Jerry,

On Sun, Mar 14, 2021 at 3:13 PM Jerry Darko <jerry.darko@cnftech.com> wrote:

Brian,

We understand the frustration for sure but it's better to have a conversation of "here's what didn't work for me", "here are some potential things to make it better", "adding xyz to the documentation would have made it better".

Better for the conversation to leave out the negative comments and give constructive criticism.

Can you point out where I had negative comments and didn't give constructive feedback?

The only reason any feedback was given was because it was requested by Davis Hoover. My initial comment, which I still feel was valid, was that the recommendation to use `git grep` was not a useful one due to the amount of intimate knowledge required about OpenCPI to understand the output.

I was then given the reason for the abstraction, and how it solves certain problems. I was also invited to supply feedback, which I feel I did without being negative, identifying ideal solution scenarios for my use cases, and providing links to examples I find useful that OpenCPI might be able to adopt.

I want to see OpenCPI succeed, and I want to be able to use it. I don't mean to be obtuse and I don't mean to be condescending. My intention for the feedback was not to bash OpenCPI but to point out major deficiencies from my point of view. If I did this in a way that was perceived as negative, let me know where and I will try to correct future interactions.

Brian