*Doc:* Also I forgot this link, which is DRC component spec itself (agnostic w/ respect to FMCOMMS/AD9361). It may be oudated... but this is about as well-documented as an API gets. (perhaps outdated) https://opencpi.gitlab.io/releases/latest/docs/Dig_Radio_Ctrlr.pdf - Davis On Mon, Mar 15, 2021 at 11:09 AM Davis Hoover <dhoover@geontech.com> wrote: > 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 > >>

On Mon, Mar 15, 2021 at 11:16 AM Davis Hoover <dhoover@geontech.com> wrote: > *Doc:* > Also I forgot this link, which is DRC component spec itself (agnostic w/ > respect to FMCOMMS/AD9361). It may be oudated... but this is about as > well-documented as an API gets. > (perhaps outdated) > https://opencpi.gitlab.io/releases/latest/docs/Dig_Radio_Ctrlr.pdf > No offense, but I don't think this documentation is as complete as you might believe. If I search for tx_rf_port or getRfOutput, I don't get any results in that PDF. Both of those things were the things I were told to `git grep` earlier in the thread which solved the issue I was having. I also don't see a mention of the DoSlave structure. Maybe this level of abstraction is one higher than what I needed, but the DRC also talks to the AD9361, so maybe the thing I needed was actually in the middle and not ultra well documented since it is so very new? What am I missing? Brian >