[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Are hierarchical blocks with a variable number of
From: |
Michael Dickens |
Subject: |
Re: [Discuss-gnuradio] Are hierarchical blocks with a variable number of inputs possible? |
Date: |
Tue, 23 Jan 2018 15:57:22 -0500 |
Hi Markus - You might be able to use the method "check_topology" <
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/basic_block.h#L339
>. You overload this method in your heir block definition & when it is called
you can internally set the number of I/O streams. This is the same technique as
done in non-heir blocks with an arbitrary number of I/O. This method should be
called just once. Hope this helps! - MLD
On Tue, Jan 23, 2018, at 3:38 PM, Markus Wirsing wrote:
> Thank you for the information.
> That already seems helpful. The functions being in the block details
> explains why I had not found them.
>
> However, I'm not sure yet whether that solves the problem entirely.
> As I build my block in the constructor, I need to know how many inputs
> there are. But at the time the constructor is called, that information
> is not known yet (it depends on what calls to connect() the next higher
> level makes).
>
> So I see two possible options:
>
> 1) If there is a way to be notified of changes in the number of inputs,
> I could rearange the instances of the subblocks each time that happens.
> For that I would probably need some callback function to be called each
> time the number changes. However, it doesn't seem to me like that
> functionality is available.
>
> 2) I take the number of inputs as a parameter to the constructor.
> Then I also would not need to query that number later on.
> And I would not have to deal with reconnecting blocks dynamically.
>
> It seems to me, like option two would be preferable.
> However, I wonder how the integration with GRC would work in each of
> those cases. I don't have experience with writing the xml-files myself
> yet. So far the gr_modtool makexml command has worked fine for me.
> But I suspect that won't be the case anymore if the number of inputs is
> not fixed at compile time.