Hi all,
I have another question. How can I connect the input and output port of
different blocks,from inside a C++ block? In the documentation I’ve only
seen the msg_connect() for python
Thanks,
marco
Hi Marco,
The top_block class has a member named: connect. You can use it in the
main() to connect different blocks. However, if you want to dis/connect
blocks within C++ blocks, you must pass top_block pointer to the class
in
some fashion. Once I did and I got errors because I didn’t have accessed
to
the “connect” from within the block.
I prefer to change your topology to refuse the need you’ve mentioned.
Otherwise describe your problem with more details.
Best,
Mostafa
On Thu, Apr 30, 2015 at 3:43 PM, marco Ribero
[email protected]
wrote:
–
Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/
excuse me,
I’m seeing the new API 3.7.7 of GNURadio which is changed. The “connect”
is
a member of gr::flowgraph which connects both blocks’ ports and message
ports:
http://gnuradio.org/doc/doxygen/classgr_1_1flowgraph.html#af8678658129a819673a59555d030aaac
Best,
On Thu, Apr 30, 2015 at 4:15 PM, Mostafa A.
[email protected]
wrote:
I have another question. How can I connect the input and output port of
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/
–
Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/
I want to exchange data between adjacent blocks which are already
connected
through the GUI, without ask to the user to write additional code.
So my approach would be: the upper block send down its name(through
tags)
and the lower block configure the communication, so I thought to take
advantage from message passing.
If I won’t be able to use this approach, I will use some memory shared
mechanism.
Just a question,in order to use the gr::flowgraph:connect(),I need to
get
the object flowgraph from the XML file situated in GRC,isn’t it?
Il giorno gio 30 apr 2015 alle ore 13:48 Mostafa A. <
[email protected]> ha scritto:
Marcus, thank you very much for your deep answer.
Your proposal about the usage of
your_block::detail()->input(0)->buffer()->link seem very interesting, so
I
shoulld evaluate if use this mechanism or only some memory allocation
created with malloc.
I’d prefer to simplify the life of user as much as possible…I’ll put my
blocks on a repository, hoping that some user will use these blocks.
Your proposal of a hierarcly approach is interesting,but in my case
could
be more problematic: user can have a DAG or graph flowgraph,and the
reserch
of the next block,performed by each involved block,could add some
complexity, considering that I need to open connection only between
adjacent blocks.
I summarize what I’m doing: as thesis ,I’m trying to make a partial
porting
over CUDA…so I’m re-implementing blocks with CUDA. Each block allocate
a
circular buffer of device pages,passing these pointer with other info to
the next block(using a tag with a pointer to host memory). Now I want to
establish an initial handshake, because the following block could have
preferences(usually not mandatory,because often the first step of a
block
is to copy data from global to shared memory,allowing some degree of
freedom) about incoming data(e.g. min-max dimension of each
page,min_multiple for input data of FFT,…). Each block receive data
throught device memory,elaborate all data and return a single useless
tap,in order to wake up other blocks…at the end of chain,data will be
copied into host memory.
Marco
Hi Marco,
ok, I think it’s best if I describe a bit of what happens behind the
curtains:
GRC is really just a graphical generator for python code. As soon as you
hit the “generate” button (or the run button, where generating is done
inherently), python code is written that has no connection, knowledge or
dependency to the XML that was used to generate it.
From a user-friendliness point of view, I can fully understand your
approach to take the burden to explicitly connect up- and downstream
blocks off your user’s shoulders. You can actually hack together
something like that even without the use of tags, by just implementing a
start() method in your block. You’d pass a top_block::sptr to the
constructor, and then, in your_block::start() get the upstream block
doing your_block::detail()->input(0)->buffer()->link(), check that
block for being your other block type, and if not, continue the search
through the flow graph in the same matter. After you’ve found your other
block, ou use your stored top_block::sptr to ->msg_connect(other_block,
this_block).
However: that breaks a lot of assumptions I would made when looking at a
flow graph, mainly the assumption that downstream blocks don’t invisibly
influence behaviour of upstream blocks. Honestly, letting your user
connect your two blocks with msg_connect doesn’t sound like a bad idea
in the long run.
Or you come up with a hier-block-based approach: – are sample streams,
message passing
.----------------------------------------------.
| your_hier_block |
|----------------------------------------------|
| |
| .------------------------. |
| | your_upstream_block | |
| |------------------------| |
| --->| |---------------->to
user blocks
| | | | |
| | ‘------------------------’ |
--------------->|— ^ |
| # |
| # |
| .------------------------. |
| | your_downstream_block | |
| |------------------------| |
| | |<----------------from
user blocks
| | | |
| ‘------------------------’ |
| | |
‘--------------------|-------------------------’
------------------------------>to
further processing
Best regards,
Marcus