|
On 05/09/2019 04:18 PM, Albin Stigö
wrote:
I absolutely agree with you. There are also other
completely unrelated issues that keep coming up like Linux,
python and x11. But I don't think there's any great harm in
ending a topic by ever-so-gently pointing people in the right
direction.
Oh, indeed, and I don't want to discourage people from "diving right
in", but that needs to be balanced with keeping the "support
envelope"
for this forum manageable.
It is the case that being really successful with a framework like
Gnu Radio requires non-trivial facility in a number of different
disciplines, and
there really is no substitute for developing that facility. I'm
fairly sure that other specialized programming frameworks go through
the same
thing, and I wonder how they cope as a community...
On
05/09/2019 02:54 PM, Albin Stigö wrote:
Every instance of a block is an
instance of the c++ class but like Nick says all
your variables are static and not member variables.
Those need to be declared in the header. Your two
block instances are referring to the same variables
and that's why things get messed up.
"A tour of C++" by Bjarne Stroustrup
is a good refresher on C++.
--Albin
I'm going to suggest, ever-so-gently, that
discuss-gnuradio, and Gnu Radio in general aren't the
places for learning C++. There are forums
already for that.
I'm saying this only because in the 15 years (!!!!) I've
been involved with Gnu Radio, I see an alarming number
of cases where the
intrepid Gnu Radio developer actually doesn't have
much in the way of programming experience in the
underlying languages used,
and arrives here, nearly-certain that their problem is
GR related, rather than an improper use of the
underlying programming language.
My guess is that other specialized-framework
environments have the same issue. Fortunately, most
people here are helpful regardless.
But it shouldn't be a growing *expectation*, IMHO.
It looks like you've declared a
bunch of static variables within your block's
namespace. Those variables (including pointers!)
will be shared with every instance of your
block. This is Bad News. Those variables should
probably all be declared in the header as class
member variables.
I'm running into a strange issue
with a new flow graph [1] I'm working
on that uses a custom C++ block [2]
that I built. The block takes input
samples, performs some DSP, and
outputs modified samples at the same
sample rate.
When the flowgraph has a single
instance of my custom block enabled,
it works fine. But when I enable a
second instance of the block in a
separate second usage, (think stereo
sound, one per sink channel) it acts
very unexpectedly - output samples are
wildly inaccurate and distorted.
My perception is that the two
instances of the same block seem to be
sharing some part of their memory
namespace and as they modify/store
variables they are doing so in some
sort of shared namespace or memory
segment.
Is it possible for two blocks to
corrupt each other's memory? I can't
think of any other explanation for the
two streams working fine individually,
but when both are enabled at the same
time the output is garbled. I've tried
all sorts of things like tying them to
the same source block, removing the
upsampling/downsampling, adding a
delay to one, etc. with no luck.
[1] "Flowgraph with two parallel streams
both using the custom block pq_rails": https://github.com/regulatre/gr-powerquality/blob/master/examples/streamer.grc
_______________________________________________
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
_______________________________________________
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
|