On Mon, Feb 13, 2006 at 09:27:42PM -0800, Ges wrote: > Hi Eric, > > I am trying to rewrite the flowgraph mechanism written in Python > into C++ so that I can run the GNU Radio modules written in C++ as > such in the Click software router. But, as I started to work on it, > i found that converting the code written in Python into C++ is not > such a trivial exercise. So right now, all I want is to have a very > simple flowgraph , so that I can try it with Click and run a graph > of gnuradio modules.
A couple of observations: If you rewrite in C++ you will kill *all* support for hierarchical blocks. If you rewrite in C++, every time somebody makes a change to the python code, your rewritten code is out of date / broken. > Firstly, do you think this is the best way to do it? Implement the > flowgraph in C++ and use that to run the gnu radio > modules. Secondly, do you have any advise on implementing this > flowgraph in C++? There is obviously a lot of functionality that I > can avoid just to get a basic mechanism to run in Click. > In short, all I would need to do is assign all the buffers for each > block, and create the connections, and then call the run() function > of the gr_single_threaded_scheduler. Am I right about this or am I > missing something very crucial? As far as I understand the code, > right now I can avoid the graph partition and the sorting mechansim > as long as I use a very straight forward gnuradio module, which does > not make any assumptions. I also feel that I can avoid a large part > of the basic_flowgraph mechanism? For a certain subset of graphs, what you're talking about will work (more or less). If you don't partition, some applications will hang. If you don't sort, cache locality for the buffers will suck. There could be other problems too. If your real goal is to couple GNU Radio into Click, my suggestion is to figure out a way to do it that doesn't require breaking the highest level (most user leverage) parts of GNU Radio. Why don't you just embed python and be done with it. Once everything is setup, the python stuff stays out of the way. This should definitely work for user-mode click, but admittedly could be a stretch for kernel-mode click. I also offer a couple of heads up: the existing hierarchical block implementation will definitely be revisited (and modified) -- it's got some warts on it that need fixing -- and the conversations about handling variable length packets will probably lead to changes in the flow graph / scheduler. John's ideas about an XMLish fix might work. I'm not sure what you would do about dynamic reconfiguration, or what it takes to hold onto references that correspond to the signal processing blocks. We often send messages to or invoke methods of the blocks after instantiation. Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
