Hi Jim,
I'm so glad you're trying this out! This is a known issue that we're hoping
to fix very soon, so you probably did everything right. In the meantime,
you could put your block in-tree for testing purposes. You can also
interact with it as "0/Block#0". I'll see if we can add a note to the guide
to indicate this might not show up correctly until the issue is resolved.
Thanks,
Wade
On Thu, Sep 17, 2020 at 9:58 AM Jim Palladino via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
> I just updated my rfnoc workflow to UHD 4.0 this week. I've gone through
> the process of creating an RFNoC block, building the corresponding FPGA
> image, putting it on an E320 (had to upgrade MPM), and seeing the block is
> present when executing uhd_usrp_probe. The problem is that the block shows
> up as "* 0/Block#0", and not "* 0/Gain#0". Basically, I'm trying to go
> through the tuturial.
>
> _____________________________________________________
> | /
> | | RFNoC blocks on this device:
> | |
> | | * 0/Block#0
> | | * 0/DDC#0
> | | * 0/DUC#0
> | | * 0/DmaFIFO#0
> | | * 0/Radio#0
>
> I've confirmed that I have a gain.yml file under my ../uhd/rfnoc/blocks
> folder with the correct noc_id. If I do a uhd_usrp_probe with the
> --init-only option, I get:
>
> ------------------------------
> [WARNING] [RFNOC::BLOCK_FACTORY] Could not find block with Noc-ID
> 0xbdc26af0, 0xffff
> ------------------------------
>
> I confirmed that this Noc-ID matches the ID in my gain.yml file. I started
> digging into uhd_usrp_probe code (I'm not a C++ person) and noticed that
> the registry_factory section of code has "FIXME TODO" under the descriptor
> registry section, but has code for the direct registry section:
>
> -------------------------------
> block_factory_info_t factory::get_block_factory(noc_id_t noc_id,
> device_type_t device_id)
> {
> // First, check the descriptor registry
> // FIXME TODO
>
> // Second, check the direct registry
> block_device_pair_t key{noc_id, device_id};
>
> if (!get_direct_block_registry().count(key)) {
> key = block_device_pair_t(noc_id, ANY_DEVICE);
> }
> if (!get_direct_block_registry().count(key)) {
> UHD_LOG_WARNING("RFNOC::BLOCK_FACTORY",
> "Could not find block with Noc-ID " << std::hex << "0x" <<
> key.first << ", 0x"
> << key.second << std::dec);
> key = block_device_pair_t(DEFAULT_NOC_ID, ANY_DEVICE);
> }
> return get_direct_block_registry().at(key);
> }
> ----------------------------------
>
> Does this mean that uhd_usrp_probe is not even looking at the yml files
> and only looks for directly registered blocks? I'm not sure what directly
> registered means and if my example "gain" block should somehow be directly
> registered.
>
> I was thinking that this is just something incomplete that doesn't work
> with UHD right now, but in the "Getting Started with RFNoC in UHD 4.0"
> guide (https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0), they
> show the Gain block showing up correctly when doing a uhd_usrp_probe.
>
> So, I don't understand why this isn't working or how it should work. Some
> background, I cloned/built:
> 1) UHD (v4.0.0.0 tag)
> 2) gnuradio (3.8.2.0 tag)
> 3) gr-ettus (maint-3.8-uhd4.0 branch)
>
> I "believe" my paths/environment are setup correctly.
>
> Thanks for any help.
> Jim
>
>
> _______________________________________________
> 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
