I forgot to say, I'm using Qtcreator to debug my GNURadio codes I do not
need any others!
The prgram is terminated at line in which I read from the input for the
first time i.e. :
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];
}
Best,
On Mon, Jul 28, 2014 at 4:05 AM, Mostafa Alizadeh <m.alizade...@gmail.com>
wrote:
> 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
