Re: [Discuss-gnuradio] Debugging printing GRC - E110

[Jose Torres]

Hi Josh, 

Thanks for your answer. Here my comments:

1. I fixed the problem just not using any return in the work function. Also, in 
BLOCK 1 work function (), I added a usleep(20), this gives enough time to the 
other blocks to run their work functions. 

2. So, does it mean that I should install the latest version of GNU radio? If 
yes, where is the link of the latest version?.

Thanks again and your comments are very useful!,

Jose 

On 24/10/2012, at 1:48 AM, Josh Blum <address@hidden> wrote:

> 
> 
> On 10/22/2012 09:28 PM, Jose Torres Diaz wrote:
>> Hi,
>> 
>> I've a kind of basic question, but it has taken me a lot of time to figure
>> out. I made a signal processing chain of blocks (very simple in facts,
>> generate PSDU then send as a message downstream, manipulate the content and
>> count the number of message that I've received). In order to debug my
>> blocks, in .cc files I'm using:
>> 
>> std::cout << std::endl << "running routine in BLOCK 1" << std::endl;
>> 
>> I populated my blocks with several messages, so I know what is going on
>> every time. I can see the messages printed out in GRC (using NO Gui
>> options). All the messages are correctly displayed, so I assumed that is
>> running OK. Then, I generated the top_block.py file and put into the E110.
>> When I run the top_block.py, I see only this:
>> 
>> python top_block.py
>> linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
>> UHD_003.004.003-1-g64d15538
>> 
>> Press Enter to quit: gr_block_executor: source <gr_block uhd st2 (2)>
>> produced no output.  We're marking it DONE.
> 
> I think its just a gnuradio version thing. We *just* recently made a
> change to work functions can return without producing samples. I
> mentioned this in the other thread.
> 
> Seriously though, if you are just doing message passing stuff, and you
> are having issue w/ returning from work. Dont return. Just dont do it.
> Either block on pop_msg_queue or spin on whatever your function needs to
> check.
> 
> The message passing is completely implemented outside of the scheduler.
> So this is one of the downsides for now. In future endeavors, this will
> be smart and integrated, and doing things like return from work will not
> be an issue.
> 
> -josh
> 
>> Thanks a lot for your help,
>> 
>> Jose
>> 
>> 
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio