Yes you're right about casting between "in" and "input_items", however, I
think this problem is somehow related to the large number input ports! I
don't why!
Here is the whole block:
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <gnuradio/io_signature.h>
#include "phich_grouping_impl.h"
int N_FS_phich(bool normal_cp){
if(normal_cp)
return 8;
else
return 4;
}
namespace gr {
namespace my {
phich_grouping::sptr
phich_grouping::make(bool normal_cp, int N_phich_group)
{
return gnuradio::get_initial_sptr
(new phich_grouping_impl(normal_cp, N_phich_group));
}
/*
* The private constructor
*/
phich_grouping_impl::phich_grouping_impl(bool normal_cp, int
N_phich_group)
: gr::block("phich_grouping",
gr::io_signature::make(N_phich_group *
N_FS_phich(normal_cp), N_phich_group * N_FS_phich(normal_cp) ,
sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
d_normal_cp(normal_cp),
d_N_phich_group(N_phich_group)
{
set_tag_propagation_policy(TPP_DONT);
}
/*
* Our virtual destructor.
*/
phich_grouping_impl::~phich_grouping_impl()
{
}
void
phich_grouping_impl::forecast (int noutput_items, gr_vector_int
&ninput_items_required)
{
for (int i=0; i<d_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
ninput_items_required[i] = 12;
}
}
int
phich_grouping_impl::general_work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
gr_complex *out = (gr_complex *) output_items[0];
// in = (const gr_complex *) input_items;
cout << "n input " << input_items.size() << endl;
int phich_in_len[d_N_phich_group];
int x = 0;
for (int i=0; i<d_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
in[i] = (const gr_complex *) input_items[i];
// reading tags
vector<tag_t> tag_len;
get_tags_in_window(tag_len,
0,
0,
ninput_items[0],
pmt::string_to_symbol("length"));
if(tag_len.size()>0)
{
phich_in_len[i] = pmt::to_long(tag_len[0].value);
x++;
}
}
gr_complex y_p[d_N_phich_group][12];
gr_complex y__p_tilt[d_N_phich_group/2][12];
// cout << "\tin[0][0] "<<in[0][0] << endl;
if (x == d_N_phich_group * N_FS_phich(d_normal_cp)) // x ==
d_N_phich_group) is for checking all the input tags are read
{
// grouping ...
for (int i=0; i<d_N_phich_group ;i++)
{
for (int k=0; k<phich_in_len[i]; k++)
{
y_p[i][k] = 0;
for (int j=0; j<N_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
}
}
........
.......
...........
// adding tag
add_item_tag(0,
nitems_written(0),
pmt::string_to_symbol("length"),
pmt::from_long(12));
cout << "PHICH grouping" << endl;
consume_each(12);
}
else
{ // if tags didn't read
produce(0, 0);
consume_each(0);
}
return WORK_CALLED_PRODUCE;
}
} /* namespace my */
} /* namespace gr */
Input to this block is a random source and its output is a file sink. I
would be glad to see the comments on the code to improve it also finding
the problem.
Best,
Mostafa Alizadeh
On Sun, Jul 27, 2014 at 10:10 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:
> As I said, you should use the gdb debugging approach to find the mistake.
> gr_complex **in = (gr_complex) input_items; shouldn't compile, because
> the types are incompatible.
>
> I can't help you any further with the information you're offering.
> Please share at least your complete general_work method, and the methods
> that you use to calculate the input numbers. I stand by my opininion
> that beauty lies in simplicity. If you want to make sure you don't do
> more "for" iterations than you have inputs, iterate over the number of
> inputs (input_items.size()) and not something you calculate yourself.
> That's the simple approach of eliminating error sources.
>
> Also, you're using a gr::block. If you play around with the forecast
> method, you might trigger situations where you are asked to produce a
> number of output items on different output streams, and have zero input
> items on some input streams; I don't see you check for that in the code
> excerpt you were sharing.
> Again, it isn't very useful to share only a portion of your block,
> especially when you are very sure yourself that this portion is correct,
> if you want help identifying what goes wrong.
>
> With best regards,
> Marcus Müller
>
> On 27.07.2014 19:21, Mostafa Alizadeh wrote:
> > Thank you for your notes Marcus,
> >
> > As you said this is unnecessary process to point to the input_items in a
> > for loop!!
> > However, this is not the problem because I checked that I have the same
> > number of iteration in the for loop as the number of input ports.
> >
> > The problem is somewhere else. *Again I must mention that if I use, only
> 8
> > input ports, the code runs perfectly,* however, with 24 inputs, it does
> > something wrong! (perhaps pointing to somewhere in the memory which is
> not
> > allocated to the input as it seemed to allocated to the input!). In
> another
> > words, when I want to access the first input of the first input port, I
> can
> > write:
> >
> > gr_complex **in = (gr_complex) input_items;
> >
> > // for example
> > cout << in[0][0] << endl;
> >
> >
> > The program terminated with unexpected error!
> >
> > Please help me, where is the problem?? :(
> >
> >
> >
> >
> > On Sun, Jul 27, 2014 at 4:21 AM, Marcus Müller <marcus.muel...@ettus.com
> >
> > wrote:
> >
> >> Having your complete general_work function wouldn't have hurt my
> >> understanding much...
> >>
> >> I really can't make out what you're trying to do without doubt.
> >>
> >> Anyway, from the code below I think "in" *must at least* have the same
> >> number of entries that your for loop has iterations; did you just try
> using
> >>
> >> d_group * N_FS(d_normal) instead of d_N_phich_group *
> >> N_FS_phich(d_normal_cp) when allocating your array?
> >> It seems to me that having two ways to determine how many inputs there
> is
> >> a likely cause for mistake. Use the size() of the input_items to
> determine
> >> how many inputs you really have, and assert(input_items.size() ==
> >> number_of_inputs_like_I_calculate_it); to make sure things line up.
> >>
> >> Also, the whole process seems unnecessary, since you do nothing more
> than
> >> copying the pointers from input_items to in; the typecast is nothing but
> >> syntactic magic and can be done by having "in = ((const gr_complex*)*)
> >> input_items;"; also, I encourage you to use the C++-style explicit cast
> >> operators (in this case, reinterpret_cast<>) for their clarity, but
> that's
> >> more a question of personal liking :)
> >>
> >> Greetings,
> >> Marcus
> >>
> >> On 26.07.2014 21:55, Mostafa Alizadeh wrote:
> >>> Hi Marcus,
> >>>
> >>> You're right. I didn't clarify the problem.
> >>>
> >>> Actually in C++, I wrote:
> >>>
> >>> block_impl::block_impl(bool normal, int group)
> >>> : gr::block("phich_grouping",
> >>> gr::io_signature::make(1, group * N_FS(normal),
> sizeof
> >>> (gr_complex)),
> >>> gr::io_signature::make(1, 1, sizeof(gr_complex))),
> >>>
> >>> // N_FS function returns 8 or 4 depends on its input.
> >>> // in the work function :
> >>> // d_normal and d_group are defined in the .h file
> >>>
> >>>
> >>> const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
> >>> for (int i=0; i<d_group * N_FS(d_normal); i++)
> >>> {
> >>> in[i] = (const gr_complex *) input_items[i];
> >>> }
> >>>
> >>>
> >>> when I set the "group" value to 3, the number of input ports would be
> 24.
> >>> In this case, I want to access to one element of "in" like this:
> >>>
> >>> cout << " in " << in[0][0] << endl;
> >>>
> >>> I got the aforementioned error!
> >>>
> >>> But when I set "group = 1" which means 8 input ports, all things are
> >> fine.
> >>>
> >>> any idea please,
> >>>
> >>> Best
> >>>
> >>
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
