[Discuss-gnuradio] Re: GNU Radio GPGPU WIP Branch Status?
On Sat, 2009-01-24 at 15:16 -0500, Michael Dickens wrote: Hi Martin - I'm hoping you can provide some feedback to me on your GNU Radio GPGPU branch. Can you tell me the status of your GPGPU WIP branch? Are you planning on implementing any of your suggested improvements? Yes, but lack of time at the moment. Do you mind if I make a copy of it, and update it to the latest trunk as well as convert it to be a component of the primary configure? I think this last piece will make it easier to use. I don't mind. In fact, you would make me very happy by doing this. Note that one of the problems is that the CUDA scheduler and circbuf emulation need changes in the heart of Gnuradio. Since I created my CUDA branch a lot of changes were made to gnuradio-core in this area and at the moment the CUDA gnuradio-core is not compatible with trunk gnuradio-core. If you eliminate the need for emulating a circular buffer, the changes are much less drastic. Also note that cuda kernels can only access memory that is instantiated in the same CPU thread. Current gnuradio-core trunk uses multiple threads, you can stop it from using multiple threads with an environment variable (I don't know from the top-of-my-head what it was. It was something like GR_SINGLE_THREADED=1.) See also the email discussion between me and Eric at the bottom of this mail, and my example for elimination of the need for emulating a circular buffer below. It looks like the scheduler runs entirely on the CPU, and certain blocks transfer data to the GPU and perform the computation there. Clearly this is a non-optimal implementation. Do you consider it working or complete in any sense (and, if so, what sense)? With allmost all CUDA application you do the scheduling on the CPU. In this sense I think my code is a good proof of concept. More comments below. The following is my take; please correct me if/where I'm wrong. - MLD I've looked at the README.cuda and the code in gr-cude, and it looks like the following is true: * Created buffering for CUDA; -created extra CUDA types for gr.io_signature. -changed scheduling so circular buffers are emulated (on the GPU) * Created host - GPU data transfer blocks; * Created a few CUDA specific blocks. The end result is that GNU Radio applications can make use of certain CUDA-specific blocks, e.g., in the WFM receiver example. But, unfortunately, the performance isn't any better than using just a CPU - generally because (1) the overhead in transferring data between the CPU and GPU; (2) buffering on the GPU doesn't allow for a simple memory mapped circular buffer (as used by most standard GNU Radio installs). (3) call-overhead. Even without the CPU-GPU transferres you still have a very substancial call-overhead when running a CUDA kernel. (1) The computational intensity (radio of computation time to data transport time, roughly) can be improved by increasing the amount of data per transfer, but with increased latency in the computation. Clearly there is a trade-off, and by default GNU Radio keeps the amount of work done per call on the order of a few 1000 items in order keep buffering within reason and latency low. Indeed. The same goes for the (large) call-overhead. Data is only transferred to the GPU at the begin of the processing chain, and transfered back to the CPU at the end of the processing chain. Even if that is done in large chunks, you still have a problem when the processing kernels are only allowed to do a small number of computations at a time. The call-overhead is very substantial. This is also true for the GPU-GPU memory copies done to emulate a circular buffer. (2) Martin designed a circular buffer emulator (of sorts) that runs on the CPU and GPU, but still each block has to copy all memory after each operation which is will reduce the computational intensity for small amounts of data processed per operation. True, Note that these copies are done entirely on the GPU, but they are initiated on the CPU. From the point of view of the CPU these are asynchronous but. But the GPU cannot run kernels while doing these copies. Improvements are suggested by: (A) switching to using pinned memory (on the GPU, I presume); Yes, see the bandwidthtest example in the CUDA SDK about this. (B) do host-to-cuda and cuda-to-host data transfers in the background to allow the host processor to doing other work; Yes, this needs pinned memory. (C) restructure the scheduler somewhat. change the scheduler so you get larger computational intensity. (more work per call) Also tune the calculation of num_blocks, num_iterations, num_threads_per_block and restructure the cuda kernel code if needed, Try to eliminate circular buffer emulation completely. (D) restructure the code so the cuda specific circular bufer emulation code is in a new baseclass gr-block-cuda in stead of scattered all over
[Discuss-gnuradio] Listen to Mp3 via FM broadcast
Hello, I just have the GNU Radio equipment setups and runs together with the Ubutun 8.10 with my Latitude D610 notebook. I have successfully test and the GNU software is running properly. Still, I have problem to run a code posted on-line by Elie Salameh. I typed and copied the code exactly as what it is, but I still fail. The error message said: u...@usrp-laptop:~/gnuradio/gnuradio-examples/python/usrp$ ./gnu_fm2.py -l 2.plsNumber of items in list 3 /home/usrp/gnuradio/gnuradio-examples/python/usrp/se-exp-steve-fossett-21jan09_0.Mp3 /home/usrp/gnuradio/gnuradio-examples/python/usrp/se-tia-presidential-inaugurations-19jan09-CQ_0.Mp3 /home/usrp/gnuradio/gnuradio-examples/python/usrp/jan-24-09-AS-Paul-Bunyan_0.Mp3 Using TX d'board A: Flex 2400 Tx MIMO B Traceback (most recent call last): File ./gnu_fm2.py, line 132, in module wfm_tx() File ./gnu_fm2.py, line 85, in __init__ if not self.set_freq(options.freq): File ./gnu_fm2.py, line 123, in set_freq r = self.u.tune(self.subdev.which, self.subdev, target_freq) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py, line 2688, in __tune r = self._real_tune(chan, db, target_freq, tr) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py, line 2089, in _real_tune return _usrp_swig.usrp_sink_c_sptr__real_tune(*args, **kwargs) TypeError: in method 'usrp_sink_c_sptr__real_tune', argument 2 of type 'int' the code #!/usr/bin/python from gnuradio import gr, eng_notation from gnuradio import usrp from gnuradio import audio from gnuradio import blks2 from gnuradio.eng_option import eng_option from optparse import OptionParser from usrpm import usrp_dbid import math, re, sys, thread, time, tempfile, os, random from gnuradio.wxgui import stdgui2, fftsink2 import wx # this function sends a command to Linux that will # use sox to transform mp3 to raw def mp3toraw(filename,outputfile): print(nice -n 19 sox \%s\ -r 32000 -t raw -f -l -c 1 %s\n % (filename,outputfile)) os.system(nice -n 19 sox \%s\ -r 32000 -t raw -f -l -c 1 %s % (filename,outputfile)) # this function will read the location of the mp3 files out of the #.pls file def read_playlist(fname): input = open(fname, 'r') playlist=[] l = input.readline() # NumberOfEntries l = input.readline() nentries = int(re.findall(NumberOfEntries=([0-9]+),l)[0]) print Number of items in list %d\n % nentries i = 1 while l: l=input.readline() filepath = re.findall(File[0-9]+=(.*)$,l) if filepath: print filepath[0] playlist.append(filepath[0]) i = i + 1 input.close() return(playlist) #this function will create a temprary .raw file that will used by the sox command def mktempfn(): tf = tempfile.mkstemp(.raw) outputfile = tf[1] os.close(tf[0]) os.remove(tf[1]) return(outputfile) # this code is used for mudulation # it takes options from the command line # most of this code is take from fm_tx4.py class wfm_tx: def __init__(self): parser = OptionParser (option_class=eng_option) parser.add_option(-T, --tx-subdev-spec, type=subdev,default=None,help=select USRP Tx side A or B) parser.add_option(-f, --freq, type=eng_float,default=90.1e6, help=set Tx frequency to FREQ (default 90.1e6), metavar=FREQ) parser.add_option(-l,--playlist, action=store, default=1.pls, help=MP3 playlist containing files to air.) parser.add_option(,--debug, action=store_true, default=False,help=Launch Tx debugger) (options, args) = parser.parse_args () if len(args) != 0: parser.print_help() sys.exit(1) if options.playlist == None: print No playlist specified\n sys.exit() # parse playlist playlist = read_playlist(options.playlist) # setup IQ rate to 320kS/s and audio rate to 32kS/s self.u = usrp.sink_c() self.dac_rate = self.u.dac_rate()# 128 MS/s self.usrp_interp = 400 self.u.set_interp_rate(self.usrp_interp) self.usrp_rate = self.dac_rate / self.usrp_interp# 320 kS/s self.sw_interp = 10 self.audio_rate = self.usrp_rate / self.sw_interp# 32 kS/s # determine the daughterboard subdevice we're using if options.tx_subdev_spec is None: options.tx_subdev_spec = usrp.pick_tx_subdevice(self.u) m = usrp.determine_tx_mux_value(self.u, options.tx_subdev_spec) self.u.set_mux(m) self.subdev = usrp.selected_subdev(self.u,options.tx_subdev_spec) print Using TX d'board %s % (self.subdev.side_and_name(),) self.subdev.set_gain(self.subdev.gain_range()[1])# set max Tx gain if not self.set_freq(options.freq): freq_range = self.subdev.freq_range() print Failed to set frequency to %s. Daughterboard supports %s to %s % (
Re: [Discuss-gnuradio] GRC question
Thanks Josh! That did the trick. I actually had to change a sink too, I've attached the file for reference, and here's the diff: sc...@lab-linux-2:~/src/gnuradio/grc/src/grc_gnuradio/usrp$ diff simple_usrp.py simple_usrp.py.save 336,337c336,337 class dual_source_c(_dual_source): constructor = (usrp.source_c, ) class dual_source_s(_dual_source): constructor = (usrp.source_s, ) --- class dual_source_c(_dual_source): constructor = usrp.source_c class dual_source_s(_dual_source): constructor = usrp.source_s 377,378c377,378 class dual_sink_c(_dual_sink): constructor = (usrp.sink_c, ) class dual_sink_s(_dual_sink): constructor = (usrp.sink_s, ) --- class dual_sink_c(_dual_sink): constructor = usrp.sink_c class dual_sink_s(_dual_sink): constructor = usrp.sink_s I can build dual grc flowgraphs fine now. As soon as I decipher how to setup the RX/TX muxes, I'll be in business! The zero setting for auto does not seem to choose well for these dual cases. I've discovered that 0x32103210 allows me to build a dual Spectrum analyzer using a pair of RFX900's, although I don't know why that setting works. I can't get a dual Siggen to work yet, but I'll keep hacking --Scott PS: GRC is really awesome On Sun, Jan 25, 2009 at 1:52 AM, Josh Blum j...@joshknows.com wrote: Funny, I was working on exactly this. The usrp dual source is underutilized, and Im giving the grc/usrp api an overhaul. It will be tested and checked in on monday. The bug you are getting now is due to me forgetting to 100% fix something after the daughter board c++ switcheroo. So for now, in grc/src/grc_gnuradio/usrp/simple_usrp.py... look for constructor = usrp.source_c and replace it with constructor = (usrp.source_c, ) sudo make install Scott Bierly wrote: Has anyone successfully used GRC with USRP Dual Source and/or USRP Dual Sink blocks? The attached .grc file and .py file are my simple test case, which bombs like this: Generating: /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py Executing: /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py Traceback (most recent call last): File /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py, line 72, in module tb = Scott_Dual_FFT_RFX900() File /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py, line 45, in __init__ tx_enb_b=True, File /usr/local/lib/python2.5/site-packages/grc_gnuradio/usrp/simple_usrp.py, line 360, in __init__ gr.io_signature(2, 2, constructor_to_size[self.constructor[0]]), TypeError: 'instancemethod' object is unsubscriptable I added the Sink to see what would happen, but originally only had the USRP Dual Source as a simple diagnostic test, and that bombed this way: Generating: /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py Executing: /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py Traceback (most recent call last): File /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py, line 56, in module tb = Scott_Dual_FFT_RFX900() File /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py, line 43, in __init__ rx_ant_b=RX2, File /usr/local/lib/python2.5/site-packages/grc_gnuradio/usrp/simple_usrp.py, line 320, in __init__ gr.io_signature(2, 2, constructor_to_size[self.constructor[0]]), TypeError: 'instancemethod' object is unsubscriptable Done I'm having a hard time figuring out from this what I might have done wrong. I will confess I don't understand how to setup the mux yet, but that does not appear to be related to this problem. I'm running off the subversion gnuradio build 10260, which contains GRC version 3.1SVN. Thanks for any help. --Scott ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio # Copyright 2008 Free Software Foundation, Inc. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 3, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 51 Franklin Street, # Boston, MA 02110-1301, USA. # import sys from gnuradio import usrp, gr # Helper Functions def _set_frequency(u, which, subdev, frequency,
[Discuss-gnuradio] Receiving from a GSM Base Station
Hi all, Has anyone some code to read the logical channels from a GSM base station? Particularly, I am interested in reading the AGCH and PCH channels. Thanks in advance. Sincerely, Jose Carlos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC question
This may help you with the muxes: see the comments for the TX and RX mux http://www.gnuradio.org/trac/browser/gnuradio/trunk/usrp/host/lib/legacy/usrp_standard.h Soon, there will be better configuration options and you will not have to deal with muxes! -Josh Scott Bierly wrote: Thanks Josh! That did the trick. I actually had to change a sink too, I've attached the file for reference, and here's the diff: sc...@lab-linux-2:~/src/gnuradio/grc/src/grc_gnuradio/usrp$ diff simple_usrp.py simple_usrp.py.save 336,337c336,337 class dual_source_c(_dual_source): constructor = (usrp.source_c, ) class dual_source_s(_dual_source): constructor = (usrp.source_s, ) --- class dual_source_c(_dual_source): constructor = usrp.source_c class dual_source_s(_dual_source): constructor = usrp.source_s 377,378c377,378 class dual_sink_c(_dual_sink): constructor = (usrp.sink_c, ) class dual_sink_s(_dual_sink): constructor = (usrp.sink_s, ) --- class dual_sink_c(_dual_sink): constructor = usrp.sink_c class dual_sink_s(_dual_sink): constructor = usrp.sink_s I can build dual grc flowgraphs fine now. As soon as I decipher how to setup the RX/TX muxes, I'll be in business! The zero setting for auto does not seem to choose well for these dual cases. I've discovered that 0x32103210 allows me to build a dual Spectrum analyzer using a pair of RFX900's, although I don't know why that setting works. I can't get a dual Siggen to work yet, but I'll keep hacking --Scott PS: GRC is really awesome On Sun, Jan 25, 2009 at 1:52 AM, Josh Blum j...@joshknows.com wrote: Funny, I was working on exactly this. The usrp dual source is underutilized, and Im giving the grc/usrp api an overhaul. It will be tested and checked in on monday. The bug you are getting now is due to me forgetting to 100% fix something after the daughter board c++ switcheroo. So for now, in grc/src/grc_gnuradio/usrp/simple_usrp.py... look for constructor = usrp.source_c and replace it with constructor = (usrp.source_c, ) sudo make install Scott Bierly wrote: Has anyone successfully used GRC with USRP Dual Source and/or USRP Dual Sink blocks? The attached .grc file and .py file are my simple test case, which bombs like this: Generating: /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py Executing: /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py Traceback (most recent call last): File /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py, line 72, in module tb = Scott_Dual_FFT_RFX900() File /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py, line 45, in __init__ tx_enb_b=True, File /usr/local/lib/python2.5/site-packages/grc_gnuradio/usrp/simple_usrp.py, line 360, in __init__ gr.io_signature(2, 2, constructor_to_size[self.constructor[0]]), TypeError: 'instancemethod' object is unsubscriptable I added the Sink to see what would happen, but originally only had the USRP Dual Source as a simple diagnostic test, and that bombed this way: Generating: /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py Executing: /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py Traceback (most recent call last): File /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py, line 56, in module tb = Scott_Dual_FFT_RFX900() File /home/scott/src/gnuradio/scott-grc/Scott_Dual_FFT_RFX900.py, line 43, in __init__ rx_ant_b=RX2, File /usr/local/lib/python2.5/site-packages/grc_gnuradio/usrp/simple_usrp.py, line 320, in __init__ gr.io_signature(2, 2, constructor_to_size[self.constructor[0]]), TypeError: 'instancemethod' object is unsubscriptable Done I'm having a hard time figuring out from this what I might have done wrong. I will confess I don't understand how to setup the mux yet, but that does not appear to be related to this problem. I'm running off the subversion gnuradio build 10260, which contains GRC version 3.1SVN. Thanks for any help. --Scott ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_wfm_rcv.py
On Thu, Jan 22, 2009 at 8:51 PM, Muhammad Abrar mabrarb...@gmail.com wrote: ok thanks When I run usrp_nbfm_rcv.py from /usr/local/share/gnuradio/ examples/usrp I the following message appear on GUI Failed to set initial Frequency How can i frequency set to listen FM. Take care 2009/1/23 Eric Blossom e...@comsec.com On Fri, Jan 23, 2009 at 12:25:25PM +1300, Muhammad Abrar wrote: Hi When I run usrp_wfm_rcv.py from /usr/local/share/gnuradio/examples/usrp I got following message. Using RX d'board A: Flex 1800 Rx MIMO B gr_fir_ccf: using SSE gr_fir_fff: using SSE FYI: No Powermate or Contour Knob found This is normal. Do you really have wideband (broadcast) FM up at 1.8GHz? Around here it's in 87MHz to 107MHz. Eric -- Engr. Muhammad Abrar Massey University Palmerston North NewZealand Mob: 0064211204202 Res: 006463586340 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Try running the program with -h so you can see the help message, e.g.: $ ./usrp_nbfm_rcv.py -h The -f flag is usually assigned to frequency settings. $ ./usrp_nbfm_rcv.py -f YOURFREQ If you don't know the frequencies of the FM carriers, well.. good hunting! -- Igor Almeida ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] reconfigure flow graph, sleep function in main
Hi -I am trying to get the example Python code fragment running taken from the "Controlling flow graphs" section of:http://gnuradio.org/trac/wiki/Tutorials/WritePythonApplicationsHere is my code:#!/usr/bin/env python
from gnuradio import gr
from gnuradio import audio
import time
class my_top_block(gr.flow_graph):
def __init__(self):
gr.flow_graph.__init__(self)
sampling_freq = 48000
ampl = 0.1
self.src0 = gr.sig_source_f(sampling_freq, gr.GR_SIN_WAVE, 350, ampl)
self.src1 = gr.sig_source_f(sampling_freq, gr.GR_SIN_WAVE, 440, ampl)
self.adder = gr.add_ff()
self.sink = audio.sink(sampling_freq)
self.amp = gr.multiply_const_ff(1) # Define multiplier block
self.connect(self.src0, (self.adder, 0))
self.connect(self.src1, (self.adder, 1))
self.connect(self.adder, self.amp, self.sink) # Connect all blocks
def set_volume(self, volume):
self.amp.set_k(volume)
if __name__ == '__main__':
my_top_block().start()
time.sleep(2) # Wait 2 secs (assuming sleep was imported!)
#raw_input ('Press Enter to quit: ')
my_top_block.set_volume(2) # Pump up the volume (by factor 2)
time.sleep(2) # Wait 2 secs (assuming sleep was imported!)
my_top_block().stop()
And here is the error:Traceback (most recent call last): File "h3.py", line 37, in module my_top_block.set_volume(2) # Pump up the volume (by factor 2)TypeError: unbound method set_volume() must be called with my_top_block instance as first argument (got int instance instead)Thanks for your help in advance,- Larry Wagner
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Simple testing Program
I want to take signal from signal generator and want to display it using usrp and gnu .any body have such program. -- Muhammad Abrar NewZealand Mob: 0064211204202 Res: 006463586340 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Does the GRC FFT block re-order its output
Does the GRC output block re-order output? I'm puzzled with respect to what I'm seeing. My normal expectation is that, given an FFT buffer of size N, that on output buf[0] to buf[N/2] = DC to nyquist buf[N/2] to buf[N] = -nyquist to DC But that isn't what I'm seeing in GRC FFT output. Clues? -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with USRP
-- Forwarded message -- From: Tushar Patel pateltusha...@gmail.com Date: Fri, 23 Jan 2009 21:28:32 -0800 Subject: problem with USRP To: Eric Blossom e...@comsec.com Hi Eric, I used the VM Ware player , on which i run my linux- UBUNTU-8.04 I am able to configure all gnu software packages perfectly, I was able to run hello world example. Now when I connect the USRP board with USB cable, the green light will flashing with 2hz freq. but after that I found that there is no such file usrp_firmware.ihx in usr/local/share/usrp/ver2 or ver4, so my hardware does not detected. so from various online help i came to know that my following procedure with latest USRP version, it will created automatically in that destination. ./bootstrap ./configure both are run perfectly but when I run the make command I get the error like fusb_linux.cc:30:28: error: linux/compiler.h: No such file or directory make[3]: *** [fusb_linux.lo] Error 1 I attached full log of ./bootstrap, ./configure and make for your further ref. I really stuck up with this problem, I tried with many version of USRP but it will give the same error. please help me. thanks and regards Tushar patel j...@jars-desktop:~/gnuradio/usrp-0.5$./bootstrap config/usrp_fusb_tech.m4:22: warning: underquoted definition of USRP_SET_FUSB_TECHNIQUE config/usrp_fusb_tech.m4:22: run info '(automake)Extending aclocal' config/usrp_fusb_tech.m4:22: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal firmware/lib/Makefile.am:60http://sources.redhat.com/automake/automake.html#Extending-aclocalfirmware/lib/Makefile.am:60: `%'-style pattern rules are a GNU make extension firmware/lib/Makefile.am:63: `%'-style pattern rules are a GNU make extension firmware/src/usrp0/Makefile.am:82: `%'-style pattern rules are a GNU make extension firmware/src/usrp0/Makefile.am:85: `%'-style pattern rules are a GNU make extension firmware/src/usrp1/Makefile.am:80: `%'-style pattern rules are a GNU make extension firmware/src/usrp1/Makefile.am:83: `%'-style pattern rules are a GNU make extension j...@jars-desktop:~/gnuradio/usrp-0.5$ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by make... GNU checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking whether C++ has bool... yes checking whether C++ has buggy scoping in for-loops... no checking whether user wants assertions... yes checking whether C++ has std::isnan... no checking whether user wants warnings... yes checking whether g++ accepts -Wall... yes checking whether g++ accepts -Woverloaded-virtual... yes checking whether user wants gprof... no checking whether user wants prof... no checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking for a BSD-compatible install... /usr/bin/install -c checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no
Re: [Discuss-gnuradio] Small cleanups for inband code
Hi again,
some more improvements, this time for the tx part only. This patch saves about
10% CPU for the test_usrp_inband_tx example.
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019
=== modified file 'usrp/host/lib/inband/symbols_usrp_rx_cs.h'
--- usrp/host/lib/inband/symbols_usrp_rx_cs.h 2007-09-05 00:43:43 +
+++ usrp/host/lib/inband/symbols_usrp_rx_cs.h 2009-01-26 01:54:15 +
@@ -25,6 +25,7 @@
// Outgoing
static pmt_t s_cmd_usrp_rx_start_reading = pmt_intern(cmd-usrp-rx-start-reading);
+static pmt_t s_cmd_usrp_rx_handle = pmt_intern(cmd-usrp-rx-handle);
// Incoming
static pmt_t s_response_usrp_rx_read = pmt_intern(response-usrp-rx-read);
=== modified file 'usrp/host/lib/inband/symbols_usrp_tx_cs.h'
--- usrp/host/lib/inband/symbols_usrp_tx_cs.h 2007-09-05 00:43:43 +
+++ usrp/host/lib/inband/symbols_usrp_tx_cs.h 2009-01-26 01:54:15 +
@@ -25,6 +25,7 @@
// Outgoing
static pmt_t s_cmd_usrp_tx_write = pmt_intern(cmd-usrp-tx-write);
+static pmt_t s_cmd_usrp_tx_handle = pmt_intern(cmd-usrp-tx-handle);
// Incoming
static pmt_t s_response_usrp_tx_write = pmt_intern(response-usrp-tx-write);
=== modified file 'usrp/host/lib/inband/usrp_rx.cc'
--- usrp/host/lib/inband/usrp_rx.cc 2009-01-12 21:31:44 +
+++ usrp/host/lib/inband/usrp_rx.cc 2009-01-26 01:54:15 +
@@ -93,6 +93,8 @@
if(pmt_eqv(event, s_cmd_usrp_rx_start_reading))
read_and_respond(data);
+if(pmt_eqv(event, s_cmd_usrp_rx_handle))
+ d_urx = boost::any_castusrp_standard_rx_sptr(pmt_any_ref(data));
}
}
@@ -115,13 +117,12 @@
unsigned int n_read;
unsigned int pkt_size = sizeof(transport_pkt);
- pmt_t invocation_handle = pmt_nth(0, data);
-
- // Need the handle to the RX port to send responses, this is passed
- // by the USRP interface m-block
- pmt_t handle = pmt_nth(1, data);
- d_urx =
-boost::any_castusrp_standard_rx_sptr(pmt_any_ref(handle));
+ if(!d_urx) {
+ std::cerr [usrp_rx] USRP RX Handle not set, shutting down\n;
+ d_cs-send(s_response_usrp_rx_read,
+ pmt_list3(PMT_NIL, PMT_F, PMT_NIL));
+ return;
+ }
if(verbose)
std::cout [usrp_rx] Waiting for packets..\n;
=== modified file 'usrp/host/lib/inband/usrp_tx.cc'
--- usrp/host/lib/inband/usrp_tx.cc 2009-01-26 01:06:02 +
+++ usrp/host/lib/inband/usrp_tx.cc 2009-01-26 01:54:15 +
@@ -83,6 +83,8 @@
if(pmt_eqv(event, s_cmd_usrp_tx_write))
write(data);
+if(pmt_eqv(event, s_cmd_usrp_tx_handle))
+ d_utx = boost::any_castusrp_standard_tx_sptr(pmt_any_ref(data));
}
}
@@ -100,7 +102,13 @@
pmt_t invocation_handle = pmt_nth(0, data);
pmt_t channel = pmt_nth(1, data);
pmt_t v_packets = pmt_nth(2, data);
- d_utx = boost::any_castusrp_standard_tx_sptr(pmt_any_ref(pmt_nth(3, data)));
+
+ if(!d_utx) {
+ std::cerr [usrp_tx] USRP TX Handle not set, shutting down\n;
+ d_cs-send(s_response_usrp_tx_write,
+ pmt_list3(PMT_NIL, PMT_F, PMT_NIL));
+ return;
+ }
size_t n_bytes;
bool underrun; // this will need to go, as it is taken care of in the packet headers
@@ -114,7 +122,7 @@
if (ret == (int) n_bytes) {
if (verbose)
- std::cout [usrp_server] Write of n_bytes successful\n;
+ std::cout [usrp_tx] Write of n_bytes successful\n;
// need to respond with the channel so the USRP server knows who to forward the result of
// the write to by looking up the owner of the channel
d_cs-send(s_response_usrp_tx_write,
@@ -122,7 +130,7 @@
}
else {
if (verbose)
- std::cout [usrp_server] Error writing n_bytes bytes to USB bus\n;
+ std::cout [usrp_tx] Error writing n_bytes bytes to USB bus\n;
d_cs-send(s_response_usrp_tx_write,
pmt_list3(invocation_handle, PMT_F, channel));
}
=== modified file 'usrp/host/lib/inband/usrp_usb_interface.cc'
--- usrp/host/lib/inband/usrp_usb_interface.cc 2009-01-26 01:06:02 +
+++ usrp/host/lib/inband/usrp_usb_interface.cc 2009-01-26 01:54:15 +
@@ -412,6 +412,11 @@
// d_utx-_write_oe(1, 0x, 0x);
// d_urx-_write_oe(1, 0x, 0x);
+ pmt_t tx_handle = pmt_make_any(d_utx);
+ pmt_t rx_handle = pmt_make_any(d_urx);
+ d_tx_cs-send(s_cmd_usrp_tx_handle, tx_handle);
+ d_rx_cs-send(s_cmd_usrp_rx_handle, rx_handle);
+
d_cs-send(s_response_usrp_open, pmt_list2(invocation_handle, PMT_T));
}
@@ -426,17 +431,7 @@
void
usrp_usb_interface::handle_cmd_write(pmt_t data)
{
- pmt_t invocation_handle = pmt_nth(0, data);
- pmt_t channel = pmt_nth(1, data);
- pmt_t pkts = pmt_nth(2, data);
-
- pmt_t tx_handle = pmt_make_any(d_utx);
-
- d_tx_cs-send(s_cmd_usrp_tx_write,
-pmt_list4(invocation_handle,
- channel,
- pkts,
- tx_handle));
+ d_tx_cs-send(s_cmd_usrp_tx_write, data);
}
/*!
@@ -455,9 +450,7 @@
if(!d_fake_usrp)
Re: [Discuss-gnuradio] Small cleanups for inband code
Awesome, thanks again Stefan! I should be able to get to this by Tuesday. - George Stefan Bruens wrote: Hi again, some more improvements, this time for the tx part only. This patch saves about 10% CPU for the test_usrp_inband_tx example. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
