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:09:00 CDT