*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_at_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 _at_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_at_gmail.com> wrote:
>
>
> Hey Jerry,
>
> On Sun, Mar 14, 2021 at 3:13 PM Jerry Darko <jerry.darko_at_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
>
>>
Received on Mon Mar 15 2021 - 15:16:21 CDT