Dear Håkon,
I am very excited to see interest in this topic! A few additional comments:
- Any new templating should be done using Mako. The new YAML format
Martin mentioned roughly looks like this:
"""
id: blocks_add_const_vxx
label: Add Const
parameters:
- id: type
label: IO Type
dtype: enum
options: [complex, float, int, short]
option_attributes:
const_type: [complex_vector, real_vector, int_vector, int_vector]
fcn: [cc, ff, ii, ss]
hide: part
- id: const
label: Constant
dtype: ${ type.const_type }
default: '0'
- id: vlen
label: Vec Length
dtype: int
default: '1'
hide: ${ 'part' if vlen == 1 else 'none' }
inputs:
- dtype: ${ type }
vlen: ${ vlen }
outputs:
- dtype: ${ type }
vlen: ${ vlen }
templates:
imports: from gnuradio import blocks
make: blocks.add_const_v${type.fcn}(${const})
callbacks:
- set_k(${const})
"""
C++ specific templates could be added under "cpp_templates" or sth.
The main part of your work would be to implement a Generator subclass.
You maybe want to checkout my latest dev version to use as a starting
point [0]
Another issue is how to deal with parameter values:
Say, I have a variable with "np.pi" as value. Or specify some filter
coeffs using a list [1, 1, 1, 1,...]. Or so some calculation "2 ** 4 + 1".
Those usually end up in the generated code somewhere. For C++ that would
fail...
I suggest, that at least some simple expressions should be transpiled
for the C++ code generation.
The alternative, writing all parameter values in C++ code, would require
a separate eval, validation, .... - basically a C++ version of GRC.
I'd rather do everything in Python and get the C++ output as a bonus on
top. This means that all blocks must still be available in Python - even
if they are just in output C++. This way we can load and instantiate
things like filter and constellation objects during design time (before
you hit generate) and do validation with those.
Sebastian
[0]
https://github.com/skoslowski/gnuradio/blob/df1e94831c05e3b8a25e5490f50ebf9e98795182/grc/core/generator/top_block.py
On 03/31/2017 02:07 PM, Håkon Vågsether wrote:
> Hi Marcus,
>
> thank you for your feedback.
>
> Also, would kind of had preferred to read "I've not used GNU Radio
> much before, but I've played around with the LiveDVD (or whatever
> you'd have done)" instead of reading "I've not used GNU Radio
> before(at all)" and seeing you use pretty dated screenshots from
> Josh's website instead of familiarizing yourself quickly, so that
> you could leave us with the certainty that hey, we don't have to
> teach you how to even start GRC ... not that I really think this
> will be any trouble for you, but the ease of getting started with
> GNU Radio, considering ready-made packages and the bootable
> liveDVD and the guided tutorials make me wonder much more why you
> didn't demonstrate you've played with GNU Radio before.
>
> Haha, I understand what you mean, and you're right! I naturally
> wouldn't post my proposal draft for this project without knowing how
> to even start GRC :) I have spent the last few weeks tinkering and
> trying to gain some familiarity with GRC and its source. I could (and
> should) have just taken a screenshot myself! I will include this in my
> next draft.
>
> Big Plus is of course that you mention Cheetah, which proves
> you've actually looked at the source code, I guess! This is
> probably not going to hurt at this stage, but as Ben said, we're
> currently replacing that with Mako (Cheetah is kinda Python2 only,
> and we're making things work with Py3).
>
> So, I hope this is not asking too much from your time right now
> (you might be busy with exams for all I know about studying), but
> I'd recommend you checkout the "next" branch of the gnuradio
> repository, and try to build it with GRC enabled, and maybe add
> some "change <filename/directory> to include <functionality>" to
> your timeline after getting a rough idea of how code gen works there.
>
> Right! I had already built it from source, but I was on the master
> branch. I've built the next branch now, and I've noticed the addition
> of the GRCC compiler.py in the grc/ directory. I suppose the GSoC
> project might as well include adding the build options as command line
> arguments to this while I'm at it.
>
> I like your block diagram, it clarifies a few things, and
> generally, I prefer reading a concise chart instead of a wall of
> text, and I think that "writing down" the current code generation
> process in terms of who-calls-what in Python in that shape would
> be awesome, because that would allow you to make a second,
> modified chart that shows what you'd like to add/change to that,
> and would also be a great starting point for the (relatively
> compact) documentation we'd like you to deliver in the end.
>
> I've made another diagram to visualise this, the dotted lined objects
> are objects that I'm planning to implement. I've tried to leave out
> the non-essential details to reduce complexity. As Ben pointed out (if
> I understood him correctly), it might not be worthwhile to create
> Makefiles directly from the templates, rather just leave it all to
> CMake. This does make sense and will save me some work.
>
> call_diag.png
> <https://drive.google.com/file/d/0B1ylsmzHTJ7Ab3p6YmN6TWxfTWs/view?usp=drive_web>
>
>
> Best regards,
> Håkon Vågsether
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
