gr_modtool.py has undergone some heavy revision recently.
It’ll now do even more stuff:
It’s been changed to the CMake version. The autotools version still
exists on the CGRAN SVN server.
You can create out-of-tree modules using ‘gr_modtool.py create’.
This is basically an improved version of create-out-of-tree-module,
because
it uses the CMake stuff and
it doesn’t give you the square_ff files which you have to remove.
Of course, there’s been bugfixes… and probably new bugs.
All you need to do is download the gr_modtool.py file and copy it
somewhere into your PATH. Then you can create new modules and add code
to it within seconds.
Example: you want to create a new module called ‘mydsp’ and add two
blocks ‘mydsp_algorithm1_ff’ and ‘mydsp_algorithm2_cc’. The first one is
a sync block, the second a hier block. Also, you’d like bindings for
GRC. This is what it might look like:
% gr_modtool.py create mydsp
Module directory is “./gr-mydsp”.
Creating directory…
Copying howto example…
Unpacking…
Replacing occurences of ‘howto’ to ‘mydsp’…
Done.
Use ‘gr_modtool add’ to add a new block to this currently empty module.
~/tmp % gr_modtool.py add -t sync mydsp_algorithm1_ff
No GNU Radio module found in the given directory. Quitting.
% cd gr-mydsp
% gr_modtool.py add -t sync mydsp_algorithm1_ff
Operating in directory .
GNU Radio module name identified: mydsp
Code is of type: sync
Block/code identifier: mydsp_algorithm1_ff
Full block/code identifier is: mydsp_mydsp_algorithm1_ff
Enter valid argument list, including default arguments: int foo, double
bar=1
Add Python QA code? [Y/n]
Add C++ QA code? [Y/n] n
Traversing lib…
Adding file ‘mydsp_mydsp_algorithm1_ff.h’…
Adding file ‘mydsp_mydsp_algorithm1_ff.cc’…
Traversing swig…
Editing swig/mydsp_swig.i…
Traversing python…
Adding file ‘qa_mydsp_mydsp_algorithm1_ff.py’…
Editing python/CMakeLists.txt…
Traversing grc…
Adding file ‘mydsp_mydsp_algorithm1_ff.xml’…
Editing grc/CMakeLists.txt…
% gr_modtool.py add -t hiercpp mydsp_algorithm2_cc
Operating in directory .
GNU Radio module name identified: mydsp
Code is of type: hiercpp
Block/code identifier: mydsp_algorithm2_cc
Full block/code identifier is: mydsp_mydsp_algorithm2_cc
Enter valid argument list, including default arguments:
Add Python QA code? [Y/n]
Add C++ QA code? [Y/n]
Traversing lib…
Adding file ‘mydsp_mydsp_algorithm2_cc.h’…
Adding file ‘mydsp_mydsp_algorithm2_cc.cc’…
Adding file ‘qa_mydsp_mydsp_algorithm2_cc.cc’…
Traversing swig…
Editing swig/mydsp_swig.i…
Traversing python…
Adding file ‘qa_mydsp_mydsp_algorithm2_cc.py’…
Editing python/CMakeLists.txt…
Traversing grc…
Adding file ‘mydsp_mydsp_algorithm2_cc.xml’…
Editing grc/CMakeLists.txt…
Takes 5 seconds. All you need to do is edit the important bits of your
files.
Hope this helps people. Have a nice weekend,
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
On Fri, Jan 27, 2012 at 06:21:05PM +0100, Martin B. wrote:
- it uses the CMake stuff :) and
GRC. This is what it might look like:
No GNU Radio module found in the given directory. Quitting.
Traversing lib…
% gr_modtool.py add -t hiercpp mydsp_algorithm2_cc
Adding file ‘mydsp_mydsp_algorithm2_cc.cc’…
Takes 5 seconds. All you need to do is edit the important bits of your
files.
Hope this helps people. Have a nice weekend,
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Example: you want to create a new module called ‘mydsp’ and add two
blocks ‘mydsp_algorithm1_ff’ and ‘mydsp_algorithm2_cc’. The first one is
a sync block, the second a hier block. Also, you’d like bindings for
GRC. This is what it might look like:
I must confess I am not a great DSP coder, but often find that blocks
that are in gnuradio itself don’t have GRC blocks defined.
Could I use your tool to add them ? For example the jack audio blocks
are there in gnuradio itself, but only the audio sink/source is in
GRC, and that talks to ALSA.
I could of course use the old “plugjack” trick, but why add the extra
latency in going thru the ALSA subsystem first ?
On Sat, Jan 28, 2012 at 11:53:57AM +0000, Iain Young, G7III wrote:
I must confess I am not a great DSP coder, but often find that blocks
that are in gnuradio itself don’t have GRC blocks defined.
No, that won’t help. gr_modtool.py only really helps for your own
out-of-tree modules. Also, the skeleton code for GRC is really basic,
and needs the most ‘hand work’ out of all the non-code files.
And yes, I’m that lazy
Lazy is good. That’s why I wrote this script.
MB
–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
I think you misunderstand. The jack audio block is intended to be a
backend, as are all other audio subsystems. They are all accessed via
one unified API, which is already available as python and GRC block
(audio sink/source). The application doesn’t know whether you are
using ALSA, JACK, portaudio, … You can choose which audio backend
to use in a configuration file, see etc/gnuradio/conf.d/gr-audio.conf
Ah, thank you Alex. I had indeed slightly mis-understood. I always knew
the Audio Sink was ALSA/JACK/Port Audio/whatever in gnuradio, Just from
the options in the GRC block, assumed it patched into ALSA -only-.
Thanks for making that clear to me, I shall try it once the new PC
arrives.
Now for the big question…I see no way within the GRC block to say
“This instance of Audio Sink goes to JACK, port x”, while another
instance goes to “ALSA hw:4,0,1”…
Anyone know of such a way within GRC ? I’m looking at grabbing a chunk
of 144MHz and:
o sending a bunch of AX.25 channels to a soundmodem driver
o other "important" (local repeaters) channels to jack, and
o specific emcomms frequencies to a bi-directional repeater running
within the same (admittedly very large) graph.
I would dearly love to be able to have both the ALSA devices and the
JACK devices within the same flow-graph, but gr-audio.conf would appear
to be global ?
On Sat, Jan 28, 2012 at 12:53 PM, Iain Young, G7III [email protected]
wrote:
I must confess I am not a great DSP coder, but often find that blocks
that are in gnuradio itself don’t have GRC blocks defined.
Could I use your tool to add them ? For example the jack audio blocks
are there in gnuradio itself, but only the audio sink/source is in
GRC, and that talks to ALSA.
I could of course use the old “plugjack” trick, but why add the extra
latency in going thru the ALSA subsystem first ?
Iain,
I think you misunderstand. The jack audio block is intended to be a
backend, as are all other audio subsystems. They are all accessed via
one unified API, which is already available as python and GRC block
(audio sink/source). The application doesn’t know whether you are
using ALSA, JACK, portaudio, … You can choose which audio backend
to use in a configuration file, see etc/gnuradio/conf.d/gr-audio.conf
and
and
