How can I get the code in EEPROM of ＵＳＲＰ

GNU Radio
1

I know that, the EEPROM stored the PID / VID and the initial program of
AD9862. But where can I get this
code? Is it in ＵＳＲＰ program?

View this message in context:
http://old.nabble.com/How-can-I-get-the-code-in-EEPROM-of-ＵＳＲＰ-tp30048920p30048920.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

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.

thanks.

al

3

On Mon, Oct 25, 2010 at 11:38:00AM -0400, Almohanad F. wrote:

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.

thanks.

al

Is there any chance that sometime you run the code as root, and
sometimes as a non-root user? If so, depending on the details of your
installation, you may have a situation where the non-root user cannot
remove the old and out of date *.pyo and *.pyc files.

I’ve never seen the problem you describe, thus I suspect that it
may have to do with permissions on the files and/or directories
involved.

Eric

4

On 10/25/2010 04:38 PM, Almohanad F. 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

5

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

6

On 10/25/2010 11:38 AM, Almohanad F. wrote:

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.

Python is supposed to delete those .pyc and .pyo files whenever you ask
it to run a matching .py file, if the .py file is younger. Otherwise,
it assumes you haven’t changed the .py file, and saves a bit of time by
jumping straight to the compiled files. One time where I’ve seen similar
behaviour is when the .py is a symlink (link.py -> real.py, say).
Opening and modifying link.py changes the modification time of real.py,
but not link.py, so if you ask python to compile link.py, it still looks
older than link.pyc that it created before you modified anything.

It’s possible there are other situations where this would happen, that’s
just the one time that I remember it happening to me.

–
Patrick Yeon
ThinkRF
613-369-5104 x418