Hi Rob, On Fri, 2019-01-25 at 17:42 -0500, Rob Kossler wrote: > Why do you compare two instances of "device" with one instance of > "multi_usrp"? Can't the device object have two IP addresses?
Nope, can't. That's what multi_usrp was designed for. Device is a single device representation. It *should* be more internal. It's a artifact from simpler times. Multi_usrp is the abstraction people should be using. > I'm not aware of a performance issue that can only be achieved > using multi_usrp as opposed to working directly with device, but > perhaps I'm wrong. As said, from the top of my head, there's differences in the way the ADCs on multi-X300 is initialized. > As an alternative example, consider the > multi_usrp::get_usrp_rx_info() > method. This method requires <uhd/eeprom.hpp> (one of the > non-installed headers I mentioned) to get the typdef eeprom_map_t. Internally, that might be. Externally, the API is a map<string,string>. > This is then used to read the daughterboard serial number and subdev > id. It seems to me that I should be able to access this information > without going through the multi_usrp API. So, you're one of my favourite customers, and I'll hardly argue with you about what you should or should not be doing with Open Source drivers, but: If you take a step back and consider the *user*, the *consumer* of UHD, then: you should go through the abstraction of multi_usrp rather than assuming something about the way the device knows "who" and "what" it is. Nobody's guaranteeing the next generation of USRP will have any EEPROM, let alone one that is programmed in a way compatible to what you see in eeprom_map_t. (This is not hypothetical. E310 has a different type of EEPROM than all the other USRPs at the point of introduction. That led to interesting abstraction clutches in drivers.) Again, what you're doing is working with internal things of UHD that we don't consider API and thus have no mercy with – if anyone has a productive reason to replace eeprom_map_t with a different type inside UHD, they just might be without pushing more than the patchlevel versioning. It's not API nor ABI of UHD. > In fact, if I have a non-standard FPGA image, I am not even ABLE to > use the multi_usrp API because legacy_compat will not "make" without > an expected set of rfnoc blocks. So, that's the pickle we're in :) RFNoC made it more likely than ever that users become modifiers of UHD. And you're a prime example; so by all means, do what you must to our code base (my recommendation is still very strongly to modify in-tree, rather than out-of-tree); the thing I'm trying to point out is that you've crossed the threshold from API consumer to in-tree developer. The things you're using should never be seen by a "normal" user of UHD. So, that's where my sympathy for this case comes from, and why I'm writing these epics in the shape of emails: while you're trying to do something that no software/hardware company could reasonably support (work with the driver internals externally), we still put you in a position where you have to do it (work with driver internals). So, let's keep this thread going, even though I'll still stress: if anything, do this internally, not externally to UHD. > But, without <uhd/eeprom.hpp> include file, I don't have the needed > eeprom_map_t typdef. Yep, you're modifying multi_usrp, an internal component of UHD, so you need internal things. Anyway, this again points out that you should be modifying UHD, not trying to reimplement things out-of-tree. Your presumption that it's easier to work externally and import these private headers than to maintain a git branch with your modification is a bit of a dangerous path, from my software architectural perspective. Again, not stopping you, but I don't think it's the safest or quickest way forward. Best regards, Marcus _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
