I found a clue today.
The constructor of my control block never gets called in the test where I use the rfnoc-vastech shared library in a totally separate project. (In an application directly compiled in my rfnoc OOT repo it definitely does get called.) It seems like the “UHD_RFNOC_BLOCK_REGISTER_DIRECT” is never being called in the first example. I’ve tried the LD_PRELOAD, but that doesn’t solve the issue. I read in comments somewhere in UHD that those macros define some code which gets executed before main() is run somehow, and perhaps that is missing in the first case. I’m not sure how that works. Thanks, 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] <mailto:[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] <mailto:[email protected]> > Sent: Friday, 21 February 2025 16:21 To: Kevin Williams <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
