Hi Wade,
Do you mean build the block controller in tree? Or do you mean place the
yml file in the uhd share folder? Or ??
Rob
On Thu, Sep 17, 2020 at 12:01 PM Wade Fife via USRP-users <
usrp-users@lists.ettus.com> wrote:
> 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, 0x
>> --
>>
>> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
