Re: [Discuss-gnuradio] Re: remark on custom block + python behavior on Beagleboard

[Almohanad Fayez]

The beagleboard wasn't complaining about the RTC but I installed a battery on the beagleboard expansion yesterday hoping that'll fix it, renewed the timestamps by "touching" everything but that didn't seem to help.  The problem gets more complicated as the code i'm working with is composed of a python file importing other custom python files.  The best fix I found is turning off PYO and PYC file generation all together using "export PYTHONDONTWRITEBYTECODE=1".  I've read a number of posts for other projects complaining about stale pyo/pyc corrupting applications I'm installing and running everything as root so I doubt file permissions is the culprit,

 I'm currently using Python 2.6 on the beagleboard, I plan on upgrading to 2.8 soon and see if the problem persists ... at least for now the environmental variable is good enough


al

-----Original Message-----
From: Philip Balister <address@hidden>
To: discuss-gnuradio <address@hidden>
Sent: Tue, Oct 26, 2010 1:48 pm
Subject: [Discuss-gnuradio] Re: remark on custom block + python behavior on Beagleboard

On 10/25/2010 04:38 PM, Almohanad Fayez wrote:

> Hi,  sent an email a while back about what I thought was a scheduler issue 

with gnuradio on the beagleboard.  Basically I've been writing custom GNU Radio 

block for the OMAP's DSP and running them on the beagleboard.  On occassions 

when I'm running multiple blocks, GNU Radio would parse my flowgraph but then 

get lost and never starts the flowgraph.  I've always thought it was an issue 

with my code but it turned out to be a python issue and I'm not sure if it's 

specific to my platform or python in general.

>

> python  basically generates optimizied pre-interpred python files  *.pyo and 

*.pyc. and as it happens, some of these files are not refreshed when I make 

changes to my python source file I managed to debug the issue where at the point 

where gnuradio calls the c++ file that handles the swig call handling 

"gnuradio_swig_py_runtime.cc".  This file is able to detect the python block so 

the "custom_blocks.cc" file generated by the howto-write-a-custom-block auto 

tools.  then there is a call placed to the constructor "gr_basic_block.cc" and 

that's where gnuradio gets lost into oblivion.

>

> I was able to finally fix this problem by writing a script that deletes all of 

the pyc and pyo files associated with my library and flowgraph.  my question is, 

is this a know python issue, an issue with the custom gnuradio block, or an 

issue with the platform?  I managed to recreate this problem using the custom 

block 3.2.1 and 3.2.2 templates and I was also able to recreate it by using the 

original how to square a number example.



Are you having real time clock issues? If you do not have the battery on 

your beagle, it will reset time each time you cycle power. That could 

explain what you are seeing. I installed the battery backup on mine to 

avoid this problem. You can also try to set the time over the network.



Philip



>

> thanks.

>

> al

>

>

>

>

> _______________________________________________

> Discuss-gnuradio mailing list

> address@hidden

> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio







_______________________________________________

Discuss-gnuradio mailing list

address@hidden

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio