Re: [Discuss-gnuradio] question developing a new block

[Marcus Müller]

Hi Andreas,

On 06/05/2015 12:51 PM, Andreas Ladanyi wrote:
> Hi Marcus,
>
>> Dear Andreas,
>>> How is it possible to fill a python grc variable block with data from
>> another block C++ variable.
>> not really. GRC variables are a concept that doesn't exist in the flow
>> graph or, really, in the python file that GRC generates. They just are
>> python variables used when setting up the block
> Setting up means to insert the block in the flow graph and configure
> them ?!
>> , and if they are used in
>> a field for which the block specified a callback method, that method
>> will be included in a python function that gets called by blocks that
>> GRC knows can change variables (e.g. GUI input elements); this mechanism
>> of calling the callbacks doesn't really work without special glue;
> ok and this glue (swig file) is produced by a process triggered by the
> make command in a gr_modtools environment ?
There's more glue involved than just swig here. Again, all the magic
that happens behind the curtain can be found when you read the generated
python code.
You'll notice that for some graphical input elements, there are
functions defined that these input widgets get instructed to inform as
soon as things change. That works because the GUI toolkits allow for
this kind of callback-emulation.
>
> How can i tell gr_modtools or make to produce a callback function or
> howto program a callback function in the C++ code and the <callback>
> xml tag in the block xml file myself for my own block so a grc python
> variable name from flow graph could be inserted in a field of my new
> block later when configuring my new block in the flow graph ?
Not at all. You'll need to analyze the way the XML blocks for example of
the qtgui widgets are written, and what the generated python code looks
like, and then you'll have to manually copy that.
>>  
>> I heartily invite you to do this the "GNU Radio way": Using message
>> passing as the way to exchange information between blocks inherently
>> solves the multithreading problems that otherwise would arise (for
>> example, assume you'd be able to change the taps of a FIR whilst that
>> FIR's work() function is working; what's the correct behaviour? How do
>> you avoid segmentation faults when the new taps are shorter than the old
>> ones?). Also, it lets users understand where data/commands flow rather
>> than hiding that behind a variable name.
> Yes i read the message passing chapter and the pmt and will go in
> detail later.
Really, do it sooner than later; I do like variables as a means of
thinking when constructing my flow graph, they are O.K. for GUI widgets,
but things get ugly the moment you really want to use them from within a
block -- as you might have noticed :) GRC variables originally were
really meant only to be used by python during flow graph creation, and
the whole dynamic reconfigurability of variables at run time came later,
but before message passing worked the way it does now -- if I may throw
in wild speculation, I'd assume that if GRC was re-invented today, it
would just set up a message handler for each block using a variable, and
just allow the block author to specify what happens in that message
handler, as well as forcing every variable-changing block to have a
message output port; but: GRC has been around for quite some time, and
its maintenance is a remarkable effort, plus people get slightly
irritated when their block XML stops working.

Is there a particular reason why you wouldn't use messages?
If you need to use a block that doesn't take instructions via messages,
write a hier block that accepts messages from the blocks inside of it,
and translates them into getter/setter calls on other blocks; or, better
even, if you think the block you want to use would profit generally from
having a message port for commands/settings, fix that up-stream. There's
virtually no overhead to having a message port/handler!

Best regards,
Marcus