discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] GR_SWIG_BLOCK_MAGIC


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] GR_SWIG_BLOCK_MAGIC
Date: Wed, 13 Jul 2005 14:51:35 -0700
User-agent: Mutt/1.5.6i

On Wed, Jul 13, 2005 at 02:16:31PM -0700, Rajaprabhu T.L. wrote:
> 
> I have been spending time trying to understand the
> "How to write to signal processing block" file.
> 
> I have some questions:
> 
> 1)What does GR_SWIG_BLOCK_MAGIC function do?

Black magic, of course ;)

    %define GR_SWIG_BLOCK_MAGIC(PKG, BASE_NAME)
    _GR_SWIG_BLOCK_MAGIC_HELPER(PKG, PKG ## _ ## BASE_NAME, BASE_NAME)
    %enddef
    
    %define _GR_SWIG_BLOCK_MAGIC_HELPER(PKG, NAME, BASE_NAME)
    class NAME;
    typedef boost::shared_ptr<NAME> NAME ## _sptr;
    %template(NAME ## _sptr) boost::shared_ptr<NAME>;
    %rename(BASE_NAME) PKG ## _make_ ## BASE_NAME;
    %inline {
      gr_block_sptr NAME ## _block (NAME ## _sptr r)
      {
        return gr_block_sptr (r);
      }
    }
    
    %pythoncode %{
    NAME ## _sptr.block = lambda self: NAME ## _block (self)
    NAME ## _sptr.__repr__ = lambda self: "<gr_block %s (%d)>" % (self.name(), 
self.unique_id ())
    %}
    
    %ignore NAME;
    %enddef
    

It performs some behind the scenes renaming so that C++ classes with
names like gr_foo end up in python as gr.foo.  It also handles some
trickery related to the boost shared pointers and getting them mapped
into python the way we want.  Finally, it defines two additional
methods: one called "block" that's used internally to do something
like a "cast",  the second method, "__repr__", gives us a reasonable
printed representation of blocks.

> 2) When you call howto.square_ff() from a python
> module, can someone explain me the control flow
> between various functions in different files. 

To write a block, the key items are your forecast and general_work
or work methods.  There's a bunch of code behind the scenes that
handles buffering, scheduling of blocks etc.  To a first order
approximation, you can ignore all of that.  Bottom line is that when
your work method is called, input_items contains pointers to the
array(s) of input samples, and output_items contains pointers to the
array(s) of output samples that your code writes.  The return value
from work or general_work is the number of output samples produced, or
-1 to indicate that you're done, hit EOF, etc.

>  "sqr = howto.square2_ff ()" 
> Which function actually returns the sqr value?
> "general_work" seems to a return integer value.

work and general_work return an integer, the number of output samples
produced.  The actual "squared values" are written into the out array.


    int 
    howto_square2_ff::work (int noutput_items,
                            gr_vector_const_void_star &input_items,
                            gr_vector_void_star &output_items)
    {
      const float *in = (const float *) input_items[0];
      float *out = (float *) output_items[0];
    
      for (int i = 0; i < noutput_items; i++){
        out[i] = in[i] * in[i];
      }
    
      // Tell runtime system how many output items we produced.
      return noutput_items;
    }
    
    
> Can you give me any other insights. We are planning to
> write to some signal processing blocks.

Study gr_block.h, gr_sync_block.h, gr_sync_decimator.h, gr_sync_interpolator.h

Take a look at the classes in gnuradio-core/src/lib/general/gr_*.{h,cc,i}

Eric




reply via email to

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