OK, some random thoughts: - Can you verify that you have <prefix>/share/uhd/modules.d/rfnoc-vastech and it contains a valid DLL name (like libvastech.so)? - (FYI: That's how the simple program finds the module) - Are you sure that the make() call triggers the registration? How are you confirming that? - How is your complex application linking against UHD? (And if you want to use your block controller, you need to link against your DLL)
--M On Thu, Feb 27, 2025 at 7:51 AM Kevin Williams <[email protected]> wrote: > Hi Martin, > > > > Just to answer the search block question: yes, I have also tried > graph->find_blocks<rfnoc::vastech::multiddc_block_control> > () but that just returns an empty list. > > > > I haven’t been able to get much further than this: > > > > When this particular line is called, then my “simple” (build from in the > OOT repo) app shows my block being registered, but the “complex” example > does not. (That make() seems to trigger the rfnoc block registration.) > > uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args); > > > > I also find it curious that neither apps link to my rfnoc driver library > yet, but the “simple” still can resolve the correct new block name > “multiddc”. > > > > Is there a way I can somehow force “UHD_RFNOC_BLOCK_REGISTER_DIRECT” to > run? > > > > Kind regards, Kevin > > > > *From:* Martin Braun <[email protected]> > *Sent:* Monday, 24 February 2025 15:11 > *Cc:* [email protected] > *Subject:* [USRP-users] Re: [EXTERNAL]Re: register custom rfnoc block > names > > > > 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/e0hDCg5KEEcGgQPcNf1T4iuss?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]
