discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Trouble With UHD Tune Request


From: Josh Blum
Subject: Re: [Discuss-gnuradio] Trouble With UHD Tune Request
Date: Thu, 19 Jul 2012 11:09:09 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1


On 07/18/2012 02:17 PM, Daniel Labarowski wrote:
> Hello,
> I'm working on a C++ block which accepts a pointer to a uhd sink and
> calls the sink's set_center_frequency method to change to a new
> frequency. Set_center_frequency requires input in the form of a
> uhd::tune_request_t and returns a uhd::tune_result_t. As a bit of
> background, I generated an out of tree module with gr-modtool.py. It
> contains this block as well as two other blocks. The other blocks can be
> used in GRC but this on cannot as it requires a pointer, so I disabled
> the installation of its xml file in grc/CMakeLists.txt and will be using
> it exclusively through c++. The issue that I am having seems to be in
> accessing the libraries for UHD.
> 
> //My call to set_center_frequency, where private_UHD_Sink is a pointer
> to a UHD Sink and private_freqs is a pointer to the first member of an
> array and current_freq sets the index of the array
> uhd::tune_result_t result_sink =
> private_UHD_Sink->set_center_freq(uhd::tune_request_t(*(private_freqs +
> current_freq)));
> 
> I first compiled my flowgraph without #including <tune_result.hpp> and
> <tune_request.hpp> in my source file. Surprisingly, things compile just
> fine without the two files. However, a c++ flowgraph which tries to use
> the block gives a nondescript error ("expected primary-expression before
> ‘(’") on the line which instantiates my block. Using one of the other
> blocks (which share the same module) in GRC returns "ImportError:
> /usr/local/lib/libgnuradio-DL_Hitemp_Blocks.so: undefined symbol:
> _ZN3uhd14tune_request_tC1Ed".
> 
> I then thought that I would try to include the two files mentioned
> above, and of course it refused to compile because it could not find the
> files. I looked at the CMakeLists.txt file included with the tag demo
> c++ example included in gnuradio and decided to add
> include_directories(${UHD_INCLUDE_DIRS}) and
> link_directories(${UHD_LIBRARY_DIRS}) to my CMakeLists.txt file in my
> src directory. The issue seems to be that many of the cmake directory
> variables on my system were not set properly. Adding "MESSAGE(STATUS,
> "GR include path: ${GNURADIO_CORE_INCLUDE_DIRS}")" to my CMakeLists.txt
> file produces "STATUS,GR include path: /usr/local/include/gnuradio" but
> this is the only GNUradio related cmake variable I have found that seems
> to have been set properly. Adding "MESSAGE(STATUS, "UHD include path:
> ${UHD_INCLUDE_DIRS}") MESSAGE(STATUS, "UHD include path:
> ${UHD_LIBRARY_DIRS}")" produces "STATUS,UHD include path: STATUS,UHD
> include path: ". I was able to get the source to compile by setting the
> UHD include path absolutely (added
> "include_directories(/usr/local/include/uhd/types)" to my CMakeLists.txt
> file - but I can't seem to find the UHD_Library_Directory so I cannot
> try setting it absolutely. The program now compiles, but the same error
> is produced in GRC as well as in the c++ flowgraph. I am wondering if
> anyone has any idea how I could go about including the appropriate UHD
> libraries or what else could be causing these errors? Thanks ahead of time!
> 

You will want to include this in your package
http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/FindUHD.cmake
and call FindPackage(UHD)

You want include_directories(${UHD_INCLUDE_DIRS})

Make sure ${UHD_LIBRARIES} is also used in your list of library linking
targets

You can also see how gr-uhd uses this find script and variables.

-josh

> -- 
> Dan
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

[Prev in Thread] Current Thread [Next in Thread]