Hi Danilo, That fifo function is also used extensively in FreeDV GUI, for similar reasons: interfacing between different sample clock domains.
I'm happy to accept a patch to address this issue, as long as everything is carefully tested across the stm32 and FreeDV GUI projects. -/- Thanks for pointing out that warning, but I'm not sure how to resolve it. Steve might have some ideas. Actually here are a few warnings in ofdm.c that are a puzzle to me. Every new gcc versions seems to throw up new warnings, probably for good reason. Maybe an assert around that part of the code would be a good idea to see if (en - st) ever goes negative in x86 builds. Don (with Steve's help) has ported the OFDM modem to the stm32 and run a few unit tests. Cheers, David On 17/09/18 02:40, Danilo Beuche wrote: > Hello codec2 developers, > > I wonder if we could/should move codec2_fifo.h and fifo.c to the stm32 > directory, as it is used exclusively there and clashes with some library > functions called fifo_read and fifo_write in the gcc library we are > using in UHSDR. Since the fifo functions are not used right in the > normal code, we simply don't include them in the builds. So not a direct > issue. > > But to be able to use the fifo function in the UHSDR firmware we would > alternatively have to rename the fifo functions in order to avoid the > name clash. I did that, but unfortunately I am right now not able to > build the stm32 code since cmake is not happy, (and I am not an cmake > expert). So I decided this as to risky since I have no way to test my > changes. I dropped that idea for now but in the long run this might be > the best idea. > > Any thoughts on that? Keep as is, Move to stm32/src or change function > names to be a little more specific? > > Anyway, not a direct problem for us in UHSDR. > > > But what I get might when compiling for the UHSDR firmware as warning > while linking could be a real problem: > > In function 'ofdm_demod', > inlined from 'freedv_comprx_700d.constprop' at > ../drivers/freedv/freedv_api.c:1808:9, > inlined from 'freedv_comprx.constprop' at > ../drivers/freedv/freedv_api.c:1983:14: > ../drivers/freedv/ofdm.c:837:23: warning: argument 1 value '4294967288' > exceeds maximum object size 2147483647 [-Walloc-size-larger-than=] > complex float work[(en - st)]; > ^ > ../drivers/freedv/ofdm.c: In function 'freedv_comprx.constprop': > ../drivers/freedv/ofdm.c:837:23: note: in a call to built-in allocation > function '__builtin_alloca_with_align' > > This error may only be visible when compiling with higher optimization > levels and a fixed mode (which we do, I compiled for mode 700D only), so > that the compiler can do all the math when compiling, and it gets > 4294967288 which translates in two-complement to -8 btw. > I don't get this, when I compile the codec2-dev source code on Linux for > the x86 architecture. > > Regards, > Danilo > > > > > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
