[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Debugging printing GRC - E110
From: |
Jose Torres |
Subject: |
Re: [Discuss-gnuradio] Debugging printing GRC - E110 |
Date: |
Wed, 24 Oct 2012 07:59:48 +1030 |
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