Brian- OK just tried it and it does resolve the names now. In network mode the .so is installed in /usr/local/lib so it throws a bunch of errors trying to load everything else in that directory but when usrp probe does finally start executing it shows the correct block names. I suppose on the embedded target I could put the .so somewhere else to avoid all these other load attempts. Do you have a recommendation?
Thanks Jeff From: Brian Padalino <[email protected]> Sent: Monday, May 17, 2021 11:08 AM To: Jeffrey P Long <[email protected]> Cc: [email protected] Subject: Re: [USRP-users] Re: [EXT] Re: RFNOC block name? On Mon, May 17, 2021 at 11:04 AM Jeffrey P Long <[email protected]<mailto:[email protected]>> wrote: Brian- I think I am getting closer here. I actually just went back to using network mode so I could debug my issues without the extra challenge of the crossdev. That is a real nice thing about the E320. So I think the usrp probe will always come back with that error because there is no controller for your custom block in that usrp probe code (Sorry my terminology is probably wrong here). As you mention the generic name is just a fact of life however I really think the getting started guide should point that out so people know what to expect. With the proper block controller called with the correct noc ID registered it seems to work now. Embedded mode should probably work now too however I think I am just going to continue in network till I get my custom design into the FPGA and then move it over. Thanks for your help on this. Just to be clear, you were able to utilize the UHD_MODULE_PATH environment variable to point to the shared library holding your controller code for your custom block, and uhd_usrp_probe was able to come back with your custom name instead of just Block. Correct? Thanks, Brian
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
