Thanks Michael, After reviewing legacy_compat.cpp, it looks like the approach could work for me. If I just use the "skip_dram" option during creation and then subsequently connect the 'Replay block' to the 'DUC', it seems like it will work. Rob
On Fri, Oct 19, 2018 at 5:52 PM Michael West <michael.w...@ettus.com> wrote: > Hi Rob, > > This is definitely one of those trying to use it in a way for which it was > not intended cases. I personally think you will spend more time trying to > mix the multi_usrp and device APIs than just re-writing the code for the > device3 API. There are a lot of subtle issues and corner cases that can > potentially cause problems. If you want to do some more exploring though, > you can look at the code in host/lib/rfnoc/legacy_compat.cpp. That is the > code responsible for connecting the blocks for the multi_usrp API and > handling all the calls from the multi_usrp API that need extra > interpretation before calling into the device3 API. > > Regards, > Michael > > On Fri, Oct 19, 2018 at 2:21 PM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> I am wondering about the possibility (perhaps advisability) of using the >> multi_usrp object (in a custom C++ application with UHD) with an RFNoC FPGA >> image that includes a custom block. I realize that the multi_usrp object is >> only advertised to work with the default image, but that doesn't mean it >> can't be used with custom ones. >> >> Specifically, I am interested in using the 'Replay' block. I would like >> to create my multi_usrp object as usual which will presumably create an >> RFNoC graph as follows: >> - transmit flow: Host -> RAM FIFO -> DUC -> Radio >> - receive flow: Radio -> DDC -> Host >> >> After multi_usrp object creation, I would like to re-wire the graph to >> replace the RAM FIFO with the Replay Block. This is desirable because it >> allows me to retain the bulk of my code that uses the multi_usrp object >> (with its handling of multiple devices and channel enumerations). I >> realize that I would still have some 'Replay' block specific code for >> populating the samples (recording) and then initiating the playback, but >> that should be relatively straightforward to implement. >> >> Let me know if this is a good or bad approach. If good, how would I go >> about re-wiring the graph? >> Thanks. >> 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
