[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] gr.file_sink() or connect() limitations?
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] gr.file_sink() or connect() limitations? |
Date: |
Fri, 6 Mar 2009 10:18:50 -0800 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Thu, Mar 05, 2009 at 10:35:37PM -0800, Francesco B. wrote:
>
> Below is a short GNU Radio pipeline. Its purpose is to write an impulse
> response to a character device node representing an FPGA (which contains a
> 4-coefficient lowpass filter), read the FPGA's output, and store said output
> in a file.
FWIW, the comment about os.fork() concerns me. If you are expecting
both parent and child to continue running GNU Radio code after
os.fork, you have a misunderstanding of our code, and possibly of fork
in general. (I'm not certain that this is what you're trying to do,
but if it is, it won't work.) There's a bunch of shared state behind
the scenes that will end up "copy-on-write" after fork, leaving the
no-longer-shared state inconsistent. A standalone call to fork is
almost never the answer to any problem. If you're trying to run an
external program from within python, consider using os.system or
os.popen.
> At least, it'd be appreciated if someone could point me to the code for
> gr.file_sink() itself. I get lost in the mass of processing blocks that make
> use of it when I try to search for it, and can't find the file_sink() block
> itself.
Using common command line tools will allow you to find the source for
any block. E.g.,
$ find . -print | grep -v \.svn | xargs grep -l file_sink
./gnuradio-core/src/lib/io/gr_file_sink.h
./gnuradio-core/src/lib/io/gr_file_sink_base.cc
The etags and/or ctags command are helpful too.
$ man ctags
Eric