I have 3 different packet deframers, and now I would like them to be
able
to send a message to a certain block about correct packet reception. In
order to do that I want to make some “phantom” block that will have
message
out port.
Noe, I wonder what is the proper way to make that block/class. Does it
have
to bee created like every other block using gr_modtool with maybe some
skipping in some CMakelilist files, or I sould just ad hoc crate .c and
.h
files in the folder where my blocks are?
I have 3 different packet deframers, and now I would like them to be able
to send a message to a certain block about correct packet reception. In
order to do that I want to make some “phantom” block that will have message
out port.
Are you looking to have a sort of control block that can apply
configuration settings to these packet deframers? Either once at
init-time or at runtime based on some conditions? If so, this also might
make sense for you:
In GRAS, your deframers would register calls for configuring packet
reception:
In the top block, when you connect flows, you can also register the
blocks into a tree. The control block could then find the deframers at
runtime and apply new settings dynamically:
Its all GRC friendly and thread safe. You could do this with messages
too, it really depends what works best or makes the most sense. Anyway,
I have just been thinking about this kind of stuff and I wanted to
share.
Thank you Josh. At the moment I wanted to make this as simple as
possible.
My idea was to make a new class(block type) and to make my impl class
inherit that class also. In that new class I would store message port
subscription and a method for sending message that deframer received
valid
message. The problem is i can’t really figure out how to make a the new
class that will be used only to be inheritted by my deframer block.
Something simillar is done with filter blocks in gnuradio, there are few
classes declared in fir_filter.h and other filters inherit that class.
As a matter of fact, an instance of Nemajas_Block will contain the data of
block is derived from a base block and gr::block directly; take
Hope that was helpful
Marcus
*unless inheritance was defined as “:(public|private|protected|) virtual
superclass” all the inheritance chain down, but from looking at the source,
I’d think this is not usually the case (especially not for sync_block).
Am 11.09.2013 10:41, schrieb Nemanja S.:
Actually my question is: is there any example where some block is derived
from two other blocks (for example from two sync blocks)?
Nemanja,
Yes, Marcus is right, this probably isn’t what you want to do. We have
some blocks that have multiple parent classes, but there is only one
path from gr::block and the other parent class has completely
different responsibilities.
What you’ll probably want to do is derive a new class from
gr::sync_block (or whatever) and then derive your actual block from
your new class, overloading the functions as needed in that new class.
I don’t think deriving from two blocks will work; C++ allows you two
have multiple superclasses, sure enough, but what deriving from two
subclasses of the same base class (at least gr::block in this case) will
give you is the so-called diamond problem. As an example let’s say
you’ve got something of the like:
class Nemajas_Block public gr::awesome_block, gr::coolness_block;
with both awesome_block and coolness_block not being abstract classes
(thus, you can create instances of awesome_block and coolness_block).
As a matter of fact, an instance of Nemajas_Block will contain the
data of an awesome_block and the coolness_block, and those two each
contain an own gr::block object.*
So there’s two basic_block s that represent your instance of
Nemajas_Block, of which only one will be connected… I haven’t tried
this, but I’d think this will lead to the GR runtime telling you to
connect the unconnected parts.
So long answer short: No, I don’t think there is an example where a
block is derived from two isolated working blocks, because that’s not a
good idea.
There are, however, examples, where, using the virtual inheritance
method, a block is derived from a base block and gr::block directly;
take gr::analog::pwr_squelch_ff. Look closely where they use the virtual
inheritance method!
I’m not quite sure however, why, for your particular problem, you can’t
take either a) the gr::blocks::file_sink way (inherit from gr::block and
from a non-block class) or b) just put your algorithmic implementation
into subclasses of a common (non-block) deframer_algorithm_base_class,
and have your block hold a pointer to an arbitrary one of those, calling
that to deframe when needed.
Hope that was helpful
Marcus
*unless inheritance was defined as “:(public|private|protected|) virtual
superclass” all the inheritance chain down, but from looking at the
source, I’d think this is not usually the case (especially not for
sync_block).
Am 11.09.2013 10:41, schrieb Nemanja S.:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.