[Discuss-gnuradio] Problems with buffer allocation
Hello, continuing with my attempt of building a block that manages two vectors in the input ports (one of 30 char and another one of 432 char), and one vector in the output of 510 char, I get the error message that I attach at the bottom of the email when I run the complete waveform where it is included. I have taken a look into gr_buffer.h but I don't really understand what it is going on. Does anybody recognise this problem or had it before? Thank you in advance. Alvaro Palomo gr_buffer::allocate_buffer: warning: tried to allocate 75 items of size 432. Due to alignment requirements 256 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. gr_buffer::allocate_buffer: warning: tried to allocate 64 items of size 510. Due to alignment requirements 2048 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. *** stack smashing detected ***: python terminated === Backtrace: = /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7eb4558] /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7eb4510] /usr/local/lib/libgnuradio-core.so.0[0xb7bf2674] /usr/local/lib/libgnuradio-core.so.0[0xb7b75ea7] /usr/local/lib/libgnuradio-core.so.0(_ZN13gr_sync_block12general_workEiRSt6vectorIiSaIiEERS0_IPKvSaIS5_EERS0_IPvSaIS9_EE+0x3a)[0xb7be999a] /usr/local/lib/libgnuradio-core.so.0(_ZN28gr_single_threaded_scheduler9main_loopEv+0x13c6)[0xb7be8226] /usr/local/lib/libgnuradio-core.so.0(_ZN28gr_single_threaded_scheduler3runEv+0x1d)[0xb7be862d] /usr/local/lib/libgnuradio-core.so.0(_ZN19gr_scheduler_thread14run_undetachedEPv+0xb2)[0xb7be63a2] /usr/local/lib/libgromnithread.so.0(omni_thread_wrapper+0x81)[0xb7a85dc1] /lib/tls/i686/cmov/libpthread.so.0[0xb7f4d50f] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e9b7ee] === Memory map: 08048000-08144000 r-xp 08:06 1665010/usr/bin/python2.5 08144000-08145000 r--p 000fb000 08:06 1665010/usr/bin/python2.5 08145000-0816a000 rw-p 000fc000 08:06 1665010/usr/bin/python2.5 0816a000-0817 rw-p 0816a000 00:00 0 0956e000-0988c000 rw-p 0956e000 00:00 0 [heap] b550-b5521000 rw-p b550 00:00 0 b5521000-b560 ---p b5521000 00:00 0 b562b000-b562c000 ---p b562b000 00:00 0 b562c000-b5e2c000 rw-p b562c000 00:00 0 b5e2c000-b5e2d000 r--s 00:09 42008716 /SYSV (deleted) b5e2d000-b5e35000 rw-s 00:09 42074255 /SYSV (deleted) b5e35000-b5e3d000 rw-s 00:09 42074255 /SYSV (deleted) b5e3d000-b5e3e000 r--s 00:09 42008716 /SYSV (deleted) b5e3e000-b5e3f000 r--s 00:09 41910410 /SYSV (deleted) b5e3f000-b5e47000 rw-s 00:09 41975949 /SYSV (deleted) b5e47000-b5e4f000 rw-s 00:09 41975949 /SYSV (deleted) b5e4f000-b5e5 r--s 00:09 41910410 /SYSV (deleted) b5e5-b5e51000 r--s 00:09 41812104 /SYSV (deleted) b5e51000-b5e59000 rw-s 00:09 41877643 /SYSV (deleted) b5e59000-b5e61000 rw-s 00:09 41877643 /SYSV (deleted) b5e61000-b5e62000 r--s 00:09 41812104 /SYSV (deleted) b5e62000-b5e63000 r--s 00:09 41713798 /SYSV (deleted) b5e63000-b5e6b000 rw-s 00:09 41779337 /SYSV (deleted) b5e6b000-b5e73000 rw-s 00:09 41779337 /SYSV (deleted) b5e73000-b5e74000 r--s 00:09 41713798 /SYSV (deleted) b5e74000-b5e75000 r--s 00:09 41615492 /SYSV (deleted) b5e75000-b5f74000 rw-s 00:09 41681031 /SYSV (deleted) b5f74000-b6073000 rw-s 00:09 41681031 /SYSV (deleted) b6073000-b6074000 r--s 00:09 41615492 /SYSV (deleted) b6074000-b6075000 r--s 00:09 41517186 /SYSV (deleted) b6075000-b609 rw-s 00:09 41582725 /SYSV (deleted) b609-b60ab000 rw-s 00:09 41582725 /SYSV (deleted) b60ab000-b60ac000 r--s 00:09 41517186 /SYSV (deleted) b60ac000-b60ad000 r--s 00:09 41418880 /SYSV (deleted) b60ad000-b60b5000 rw-s 00:09 41484419 /SYSV (deleted) b60b5000-b60bd000 rw-s 00:09 41484419 /SYSV (deleted) b60bd000-b60be000 r--s 00:09 41418880 /SYSV (deleted) b60be000-b60bf000 r--s 00:09 41320574 /SYSV (deleted) b60bf000-b60c7000 rw-s 00:09 41386113 /SYSV (deleted) b60c7000-b60cf000 rw-s 00:09 41386113 /SYSV (deleted) b60cf000-b60d r--s 00:09 41320574 /SYSV (deleted) b60d-b60d1000 r--s 00:09 4168 /SYSV (deleted) b60d1000-b60e rw-s 00:09 41287807 /SYSV (deleted) b60e-b60ef000 rw-s 00:09 41287807 /SYSV (deleted
[Discuss-gnuradio] Using different sizes for the different input ports of one GNU Radio block
Hello, I would like to know if it is possible to use different data types or different vector sizes for the different input ( or output) ports of a GNU Radio block. I explain myself. When the input or output signature of a block is specified, the parameters provided are: minimum number of ports, maximum number of ports and size of the data. This size is applied to all the ports. My question is that if there is any way of specifying different sizes for the different ports. More concretely, in my case I need two input ports where one of them takes a vector of 30 char and a vector of 432 char the other. Since I can only provide one size, I'm specifying 432*sizeof_char, so when I run my flowgraph I get an error message complaining about a size mismatch. Thanks. Best regards. Alvaro Palomo -- -- Alvaro Palomo Navarro Institute of Microelectronics and Wireless Systems Electronic Engineering Department National University of Ireland, Maynooth Maynooth, Co. Kildare, Ireland P: +353-1-7086935 F: +353-1-7086027 W: www.imws.nuim.ie -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem trying to implement Reed Solomon encoder
Hi Stevie, thank you very much for the advice. I have tried to compile it removing the extern C wrap but it is not working, it keep on displaying the same error message. Maybe I'm wrong, but since all the files in the directory lib/reed-solomon are written in C instead of C++, isn't the wrap extern C necessary in my C++ component code? Thanks again. Alvaro stevie.glass wrote: Hi, Your problem is because you are not *linking* with the Reed/Solomon library. The problem is that you've wrapped the '#include fixed.h' inside an 'extern C' block. If you remove it then you'll be one step closer to getting it working. Is mise, Stevie ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem trying to implement Reed Solomon encoder
Hello,
I'm trying to create a GNU Radio block that carries out a Reed Solomon
coding based on the functions provided into the
directory /gnuradio-core/src/lib/reed-solomon.
As an example I have taken the block gr_encode_ccsds_27 that can be
found in the directory /gnuradio-core/src/lib/general since it uses the
functions implemented in /gnuradio-core/src/lib/viterbi.
Basically the aspect of my gr_rs_encoder_vbb.cc file is the following:
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include gr_rs_encoder_vbb.h
#include gr_io_signature.h
extern C {
#include ../reed-solomon/fixed.h
}
gr_rs_encoder_vbb_sptr
gr_make_rs_encoder_vbb()
{
return gr_rs_encoder_vbb_sptr(new gr_rs_encoder_vbb());
}
gr_rs_encoder_vbb::gr_rs_encoder_vbb()
: gr_sync_block(rs_encoder_vbb,
gr_make_io_signature(1, 1, (223)*sizeof(char)),
gr_make_io_signature(1, 1, 255*sizeof(char)))
{
}
gr_rs_encoder_vbb::~gr_rs_encoder_vbb()
{
}
int
gr_rs_encoder_vbb::work(int noutput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const unsigned char *in = (const unsigned char *)input_items[0];
unsigned char *out = (unsigned char *)output_items[0];
for (int i = 0; i noutput_items; i++)
{
unsigned char *temp_first_element = out;
for (int j = 0; j (223); j++)
*out++ = *in++;
ENCODE_RS(temp_first_element,--out);
}
return noutput_items;
}
I include the file fixed.h since I want to use the implementation of the
CCSDS standard (255,223).
When I execute make into the main folder of GNU Radio for compiling
everything I get the following ERROR message:
/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-virtual -pthread -o benchmark_dotprod_fff
benchmark_dotprod_fff.o
/home/apalomo/software/gnuradio-3.1.3/gnuradio-core/src/lib/libgnuradio-core.la
libtool: link: g++ -g -O2 -Wall -Woverloaded-virtual -pthread
-o .libs/benchmark_dotprod_fff
benchmark_dotprod_fff.o
/home/apalomo/software/gnuradio-3.1.3/gnuradio-core/src/lib/.libs/libgnuradio-core.so
/home/apalomo/software/gnuradio-3.1.3/omnithread/.libs/libgromnithread.so -lrt
/usr/lib/libfftw3f.so -lm -pthread
/home/apalomo/software/gnuradio-3.1.3/gnuradio-core/src/lib/.libs/libgnuradio-core.so:
undefined reference to `encode_rs_8'
collect2: ld returned 1 exit status
make[4]: *** [benchmark_dotprod_fff] Error 1
make[4]: Leaving directory
`/home/apalomo/software/gnuradio-3.1.3/gnuradio-core/src/tests'
make[3]: *** [all-recursive] Error 1
It looks like I'm missing to include another file somewhere, but I have
no idea where.
Have anybody tried to implement this yet or anybody knows how I could
fix it?
Thank you very much.
Best regards.
Alvaro Palomo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problems with Reed-solomon and Viterbi encoders
Hello, my name is Alvaro Palomo. For the last few months I've been working with the GNU Radio architecture and now I'm having some troubles understanding a part of it. I hope somebody can give me a hand. My problem is related to the Reed-solomon and Viterbi components. In the trunk they are placed in the folder /gnuradio-core/src/lib/viterbi and /gnuradio-core/src/lib/reed-solomon respectively, well, I suppose you already know this :). The thing is that I see that there is not any .i swig file associated to these two implementations in those directories. So I can't find they way of using them when I create my flow graph with Python. Maybe this is an easy issue, but I'm really struggling with it. Any help would be very very appreciated. Cheers. Alvaro Palomo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
