Re: Python module: object as a reference (just as "Block ID" in "Function Probe" block)

[CEL]

Hi Lukas,

On Fri, 2020-02-21 at 00:24 +0100, Lukas Haase wrote:
> These blocks support a message interface but unfortunately this is pretty 
> useless except for the simplest applications (I need to control advanced 
> tuning with timed commands, GPIO ports etc).

That's very much supported, far as I know: you send PMT dictionaries
containing a time spec and the setting you want to do. 
That is, if your USRP supports that, you can do it with GNU Radio.

> Hence I need to call the methods of these objects directly but I need a 
> reference to them inside my custom block.

From a software architecture point of view: no, you don't :) 

> Within my python block I cannot reference the parent blocks, hence I need to 
> pass a reference to these two objects via the constructor (and parameters).
> Basically I want to do the same as parameter "Block ID" from the block 
> "Function Probe" does.
> 
> What is the best way to implement this?

Not implementing this at all, since the resulting flow graph makes
assumptions on the order of initialization, and other things that you
really shouldn't depend on, since they can't be assumed.

> Param - Usrp Source Block(usrp_source_block):
>       Value "uhd_usrp_sink_0" cannot be evaluated:
>       name 'uhd_usrp_sink_0' is not defined

Exactly this! 

So, really, if this is about setting the gain as a timed command, then
follow [1] and use a "time" field.

For GPIO, you're right, there's no message handler for that. But as far
as I'm concerned, you *really* don't want to set GPIO things without a
message handler, as this could lead to undefined device states if
another thread (here, the one running the work() of your
uhd_usrp_source block, or a message handler) is manipulating device
state. Generally, on classic gen<=3 USRPs, the command queue is head-
blocked – and thus, you'll need to send in all commands in order.
Therefore, a call to get something (e.g. the state of GPIOs) after a
timed command call might then block, and things get logically
complicated pretty quickly.

Now, how to solve your issue?

Honestly: At this point, I'd recommend just patching the
uhd_block_impl.cc, probably. Look for `REGISTER_CMD_HANLDER` and
imitate that line.

Best regards,
Marcus


[1] http://marcus.hostalia.de/gnuradio-3.8.1.0-rc1/page_uhd.html

smime.p7s
Description: S/MIME cryptographic signature