Hi Jeff, I have been using UHD with custom RFNoC and an N310. Here are a few remarks:
- I am surprised that you can't run multi_usrp with an N310 once you remove DDCs and DUCs. I thought that multi_usrp had the smarts to essentially skip the DUC and DDC if either the blocks were missing or if the user explicitly specified skip_duc, skip_duc in the make args (see legacy_compat.cpp). But, even if this worked as expected, it still wouldn't solve your issue of handling custom flow graphs. - I believe you are correct in saying that certain functions are not provided outside of multi_usrp. Because of this, I had to create my own class, 'my_rfnoc_usrp', which inherited multi_usrp.hpp and I essentially copied the code from muti_usrp_impl for all functions that didn't have an equivalent rfnoc function. But this was not a trivial task. If you are only interested in a few select functions, you could just copy the code from multi_usrp_impl for those functions. - I believe you are correct in saying that 'master' changes this architecture. From what I understand, 'master' is the better approach in the long run, but I'm just not sure how stable this new branch is in comparison to 3.15.LTS. And, these changes go along with some pretty major changes on the FPGA side. So, moving to 'master' may be a pretty big undertaking. - You should not use rfnoc dev branch as this has been dormant for a long time (a couple of years) Rob On Tue, Mar 17, 2020 at 8:59 PM Long, Jeffrey P. via USRP-users < [email protected]> wrote: > I have been working on applications to control a N310 directly using the > uhd api. As I work with the code I am noticing there is a difference in the > way you bring up a usrp in what I will call the traditional (legacy) > uhd::multi_usrp::make() approach vs the newer uhd::device3::make approach > which seems to only appear in the examples that are specifically rfnoc. I > realize you can use the legacy approach and examples to run on the N310 but > as soon as I start modifying the FPGA image and manually take out the DDC > and DUC for example it does not like that and seg faults. I am guessing it > is looking for those blocks and doing a whole rfnoc block enumeration thing > under hood and getting mad? I have been successful using the rfnoc > (device3) examples on my tweaked FPGA image and I am currently using 3.15 > LTS. > > > > So I would like to do the following and am asking how best to proceed? > > > > -I want to remove DDC and DUC blocks from the FPGA build to make room for > my own stuff. > > > > -I would like to have full uhd api capability and it appears some things > are missing like the sensor query that seems to be available only via > multi_usrp using the traditional approach. If you look at the rfnoc > examples they have TODOs in those sections. > > > > I did notice that in the latest master branch there is a mb_controller > class that looks like it might make that stuff available. It makes sense to > me that the radio_ctrl would not have that motherboard type stuff but in > the lastest release branch it only seems to be available via the > traditional multi-usrp approach. > > > > So do I need to use the master branch if I want full capability using the > newer api or is there some other way to get to things like the sensor > query? Or should I use the rfnoc dev branch? It seems master has more than > even rfnoc at this point. > > > > Thanks > > Jeff Long > > > > > _______________________________________________ > USRP-users mailing list > [email protected] > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
