Hi Rob, On Fri, 2019-01-25 at 15:02 -0500, Rob Kossler wrote: > 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.
One could argue that, but historically this has not been the case. R&D might be cleaning this up corrently. > 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. Yeah, but I'll be honest, these are still headers that describe details. And you really shouldn't be using headers of C++ classes with non-visible symbols; as said: linker errors waiting to happen > 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. Well, that's what drivers are, ain't they? Convenience wrappers to abstract hardware interaction. > 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. But it's not really true. For example, with two uhd::usrp::device instances instead of a mulit_usrp with two IP addresses, you can't get the same level of ADC phase sync on X3xx, IIRC. > 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. indeed, that sounds like what UHD has become :) > > Regarding my goal with multi_usrp, I want a "multi_usrp-like" object > that can handle arbitrary rfnoc graphs. Ah, that sounds interesting! > 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. Yeah, that's how I'd describe a "classical" NoC flow graph. However, there's technically actually nothing forcing NoC blocks to always send their outputs to the same "downstream block"; that's a choice the noc_shell does by default. But I disgress... > 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". That's actually pretty nice, I like that approach. Martin? > 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. Well, the problem with the out-of-tree in current UHD's includes (far as I can tell), that you're also dependent on ever-changing includes. Cheers, Marcus > 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
