diff options
Diffstat (limited to 'gnuradio-core')
-rwxr-xr-x | gnuradio-core/src/examples/mp-sched/synthetic.py | 4 | ||||
-rwxr-xr-x | gnuradio-core/src/examples/mp-sched/wfm_rcv_pll_to_wav.py | 2 | ||||
-rw-r--r-- | gnuradio-core/src/lib/general/README | 98 |
3 files changed, 3 insertions, 101 deletions
diff --git a/gnuradio-core/src/examples/mp-sched/synthetic.py b/gnuradio-core/src/examples/mp-sched/synthetic.py index 4b509af228..6f0bb85da8 100755 --- a/gnuradio-core/src/examples/mp-sched/synthetic.py +++ b/gnuradio-core/src/examples/mp-sched/synthetic.py @@ -29,7 +29,7 @@ import os class pipeline(gr.hier_block2): def __init__(self, nstages, ntaps=256): """ - Create a pipeline of nstages of gr.fir_filter_fff's connected in serial + Create a pipeline of nstages of filter.fir_filter_fff's connected in serial terminating in a blocks.null_sink. """ gr.hier_block2.__init__(self, "pipeline", @@ -38,7 +38,7 @@ class pipeline(gr.hier_block2): taps = ntaps*[1.0/ntaps] upstream = self for i in range(nstages): - op = gr.fir_filter_fff(1, taps) + op = filter.fir_filter_fff(1, taps) self.connect(upstream, op) upstream = op diff --git a/gnuradio-core/src/examples/mp-sched/wfm_rcv_pll_to_wav.py b/gnuradio-core/src/examples/mp-sched/wfm_rcv_pll_to_wav.py index 2f638e26ec..7cf3210b0e 100755 --- a/gnuradio-core/src/examples/mp-sched/wfm_rcv_pll_to_wav.py +++ b/gnuradio-core/src/examples/mp-sched/wfm_rcv_pll_to_wav.py @@ -68,7 +68,7 @@ class wfm_rx_block (gr.top_block): 0.1, # passband ripple 60) # stopband attenuation #print len(chan_filt_coeffs) - chan_filt = gr.fir_filter_ccf (chanfilt_decim, chan_filt_coeffs) + chan_filt = filter.fir_filter_ccf (chanfilt_decim, chan_filt_coeffs) #self.guts = analog.wfm_rcv (demod_rate, audio_decimation) diff --git a/gnuradio-core/src/lib/general/README b/gnuradio-core/src/lib/general/README deleted file mode 100644 index 5fa18d7f64..0000000000 --- a/gnuradio-core/src/lib/general/README +++ /dev/null @@ -1,98 +0,0 @@ -Files beginning with Gr* define classes that inherit from VrSigProc. -These are high level signal processing modules that can be glued -together in your signal processing chain. - -All the others are either lower level routines which implement the -functionality of the Gr* modules, but are easier to test (fewer -dependencies), or they are general purpose. - -gr_fir_???.{h,cc}, where ??? are in F, S or C are low level Finite -Impulse Response Filters. These turn out to be where the bulk of the -cycles are burned in many applications. The ??? suffix specifies the -input type, output type and tap type of the arguments. We've -implemented the most frequently used ones. - -[Once upon a time this stuff was done with templates -(gr_fir<iType,oType,tapType>), but this turned out to be a headache. -The code appeared to trigger a bug in GCC where we were getting -multiple definitions of unrelated stuff when we started subclassing -partially specialized templates. It was also not obvious as to to -what combinations of iType, oType and tapType actually worked. We're -now explicit, and the world is a safer place to live...] - -The top level routines for FIR filtering are: - - GrFIRfilterFFF : Float input, Float output, Float taps - -- general purpose - - GrFIRfilterCCF : Complex input, Complex output, Float taps - -- applying real filter to a complex signal - - GrFIRfilterFCC : Float input, Complex output, Complex taps - -- applying complex filter to float input - - GrFIRfilterSCC : Short input, Complex output, Complex taps - -- applying complex filter to short input. Quantizes complex - coefficients to 16 bits and uses MMX or SSE2 as appropriate - - -The combination of down conversion (frequency translation) and channel -selection (filtering) is performed with: - - GrFreqXlatingFIRfilterSFC : Short input, Float taps, Complex baseband output - -- quantizes complex coefficents to 16 bits and uses MMX or - SSE2 (128-bit MMX) as appropriate [optimization to be done]. - - GrFreqXlatingFIRfilterFFC : Float input, Float taps, Complex baseband output - -- 3dnow or SSE as appropriate. - - -[ The stuff described from here down is used to implement the routines - above. This info is only relevant to those who are hacking the internals ] - - -A bit of indirection is involved in selecting the fastest -implementation for any given platform. The lower level classes -gr_fir_FFF.h, gr_fir_CCF, gr_fir_FCC and gr_fir_SCC have i/o -signatures similar to the high level clases above. These -should be considered the abstract base classes that you -work with. Note that they are not actually abstract (they've got a -default implementation; this might be considered a bug), but they -should not be directly instantiated by user code. - -Instead of directly instantiating a gr_fir_FFF, for example, your code -should actually: - - #include <gr_fir_util.h> - - // let the system pick the best implementation for you - gr_fir_FFF *filter = gr_fir_util::create_gr_fir_FFF (my_taps); - -Clear? The same for all the other gr_fir_XXX's. - - - -Performance hacking can be done by subclassing the appropriate -base class. For example, on the x86 platform, there are two -additional classes derived from gr_fir_FFF, gr_fir_FFF_sse and -gr_fir_FFF_3dnow. These classes are then made available to the rest -of the system by virtue of being added to gr_fir_sysconfig_x86.cc, -along with any guards (CPUID checks) needed to ensure that only -compatible code is executed on the current hardware. - - -TO DO ------- - -* Move all the machine specific code to a subdirectory, then have -configure symlink to the right directory. This will allow us to build on -any platform without choking. There is generic code for all routines, -only the machine dependent speedup will be lacking. - -* Add an interface to gr_fir_util that will return a vector of all -valid constructors with descriptive names for each i/o signature. -This will allow the test code and benchmarking code to be blissfully -ignorant of what platform they're running on. The actual building of -the vectors should be done bottom up through the gr_fir_sysconfig -hierarchy. - |