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]
<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]
