OK, sounds like you're more than halfway there. Also, you can ignore UHD_REGISTER_EXTENSION() for now, that's for a different purpose.
The way I've been testing "simple" applications is through probe_gain_block.cpp. The way I've been testing "complex" applications is through the GNU Radio integration. I need to see if I can reproduce your issue that way. What happens when you do try graph->find_blocks<rfnoc::vastech::multiddc_block_control> ()? In your complex case, can you try LD_PRELOADing the rfnoc-vastech OOT module? --M On Fri, Feb 21, 2025 at 3:42 PM Kevin Williams <[email protected]> wrote: > Hi Martin, > > > > I did use the new UHD 4.8 rfnoc_modtool for this block. > > > > I have the “UHD_RFNOC_BLOCK_REGISTER_DIRECT” macro as in here: > > > > UHD_RFNOC_BLOCK_REGISTER_DIRECT( > > multiddc_block_control, 0x666F0002, "MultiDDC", CLOCK_KEY_GRAPH, > "bus_clk"); > > > > I note that it is not the macro “UHD_REGISTER_EXTENSION”. > > > > It is curious, because a simple C++ application I built does recognize the > new block, and resolves its name in the static connections query, and does > correctly connect that block in my graph. > > > > In a more complex application but compiled on the same host this block is > not found, and the static link report also only shows it as “* > 0/Block#0:0==>0/SEP#2:0” etc. > > > > I also note that the more complex application is linked to my rfnoc driver > library. > > > > I’m not sure where to look next as I have a python script which confirms > the noc_id read back from the usrp is the same as what I expect in the > driver, and I also tried the > “graph->find_blocks<rfnoc::vastech::multiddc_block_control>” instead of > just uhd::rfnoc::block_id_t(0, "MultiDDC", 0) which also does not find > blocks of the type in question. > > > > Kind regards, Kevin > > > > *From:* Martin Braun <[email protected]> > *Sent:* Friday, 21 February 2025 16:21 > *To:* Kevin Williams <[email protected]> > *Cc:* [email protected] > *Subject:* [EXTERNAL]Re: [USRP-users] register custom rfnoc block names > > > > Hey Kevin, > > > > yes, you need that macro, as here: > https://github.com/EttusResearch/uhd/blob/master/host/examples/rfnoc-gain/lib/gain_block_control.cpp#L55-L56 > <https://url.za.m.mimecastprotect.com/s/EoS3C98BNNi2ZMRhofXTqRd1S?domain=github.com> > > > > Are you using rfnoc_modtool? Because rfnoc_modtool add should create all > the relevant boilerplate. > > > > If you're using the latest rfnoc_modtool, then the OOT module will also > have all the hooks in place to automatically register your OOT with UHD, no > need for LD_PRELOAD. > > > > --M > > > > On Fri, Feb 21, 2025 at 4:50 AM Kevin Williams < > [email protected]> wrote: > > Hi Everyone, > > I think this is my last hurdle. > > I have a C++ application using my custom rfnoc block drivers, but the > "LD_PRELOAD" variable does not help when resolving the block names in the > image. > > I do see my rfnoc driver shared library being linked to the app binary. > > Its not clear how to do this. > > In the docs I see the "UHD_REGISTER_EXTENSION" macro which has left me > wondering if this is perhaps the answer. > > If this is correct is there an example I could follow? (I don't see this > macro used in the UHD repo, and it doesn't appear in my web search > results.) > > Kind regards, Kevin > > _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
