Thanks Marcus,
Regarding the installation of the header files,
- my hypothesis is that if they are located in the <uhd/*> tree, they
are intended to be installed. If they are located in the <uhdlib/*> tree,
they are not intended to be installed. Otherwise, I don't understand the
distinction of the two trees and why you would choose to locate a given
header file in one tree rather than the other.
- and from a conceptual perspective, it seems to me that multi_usrp is a
"convenience" class intended to make it easy to access device capability
through access methods rather than directly manipulating the property
tree. If that is true, then it seems to follow that there would be nothing
in the multi_usrp API that I couldn't accomplish "manually" outside of that
API. Given that the stock multi_usrp implementation "requires" the
non-installed header files, this would tell me that there is certain
functionality that can only be accomplished through the multi_usrp API and
not otherwise.
Regarding my goal with multi_usrp, I want a "multi_usrp-like" object that
can handle arbitrary rfnoc graphs. A few remarks:
- the current multi_usrp implementation handles rfnoc FPGAs using
"legacy_compat" to handle the rfnoc graph and rfnoc block details
- legacy_compat does not allow the user to specify a custom rfnoc
graph (such as one containing an FFT block), but rather
constructs a graph
based on the notion of Tx looking like (host->fifo->duc->radio) and Rx
looking like (radio->ddc->host). You can "skip" various
elements with the
appropriate "arg" setting but otherwise your graph looks like multiple
channels of this.
- legacy_compat also has the limitation that a "radio channel" is
one-to-one with a "streaming channel". Thus, you could not have a graph
with a single streaming channel and two radio channels such as the
following: host->SplitStream=>Dual DDC=>Dual Radio.
- So, in my current implementation, I have replaced "legacy_compat" with
my own "rfnoc_chan_map" and so I copied and slightly modified
"multi_usrp_impl" to interface with my "rfnoc_chan_map". My implementation
- requires the user to specify a graph using a text file containing
every "link" (starting node & ending node). The graph filename is passed
via make "args".
- keeps track of all radio sink and source blocks (as well as duc/ddc
blocks if directly attached to the radios) as Tx and Rx radio channels
(e.g., for accessing radio settings)
- keeps track of all "host_tx" and "host_rx" "blocks" as Tx and Rx
streaming channels (e.g., for getting tx/rx_streamers).
- Since my custom "mult_usrp" implementation is derived from
"multi_usrp.hpp". I should be able to use it in most/all of my existing
applications.
- As to why I don't just modify the stock multi_usrp, as you see, that
is what I have done. But, I have done so out-of-tree rather than in place.
This just seems easier to me given the frequency of uhd updates that I pull
and would need to modify if working in-tree.
Rob
On Fri, Jan 25, 2019 at 1:49 PM Marcus Müller <marcus.muel...@ettus.com>
wrote:
> Hi Rob,
>
> you've got a point – in soft_register.hpp, there's classes that contain
> exported symbols, it should probably be installed.
>
> component_file.hpp, dirty_tracked.hpp and eeprom.h really only contain
> implementation details; I'm not the UHD maintainer, but I'd say these
> files shouldn't get installed, as the types defined therein are only
> used in non-public-API functionality, and thus are subject to change
> without notice. Don't depend on these types existing!
>
> In fact, they can change without the UHD ABI compat version being
> bumped, as far as I'd set a versioning policy. These are internals!
>
> The problem you're setting yourself up, IMHO, is that even if you have
> all the headers, the symbols (function bytecode) are still in libuhd.so
> and not necessarily exported (that's what UHD_API does), so you might
> end up coding something that compiles very fine and then fails to link
> unless you start modifying default visibilities, at some surprising
> point during development.
>
> Hey, maybe there's an easy way out. Can you tell us what you're doing
> in your custom multi_usrp, and why you're not simply modifying the
> stock multi_usrp?
>
> Best regards,
> Marcus
>
>
> On Thu, 2019-01-24 at 18:09 -0500, Rob Kossler via USRP-users wrote:
> > While attempting to create a custom "multi_usrp" implementation
> > (based on an arbitrary rfnoc graph), I found that the following files
> > are not "installed"
> > <uhd/types/eeprom.hpp>
> > <uhd/types/component_file.hpp>
> > <uhd/utils/soft_register.hpp>
> > <uhd/utils/dirty_tracked.hpp>
> >
> > I noticed this because I tried to compile a copy of "multi_usrp.cpp"
> > out-of-tree. The compile failed because of missing include files (all
> > of the above except component_file.hpp). I then looked in the
> > CMakeLists.txt files for these folders and sure enough, these files
> > are not included. I am wondering if this is intentional or a mistake
> > - it seems the latter.
> >
> > By the way, I also had an issue with needing
> > <uhdlib/usrp/gpio_defs.hpp>, but this one is in the lib tree so I
> > understand why it is not installed. In any case, I just copied all
> > of the needed include files out-of-tree and was able to compile.
> > Rob
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
