Hi Danilo
I agree with you in the memory constrained environment-
Actually with the change in fft, I have reduced the peak memory
requirements.
the new FFT is in-place.. and all the cmsis needs is a config structure,
as all the twiddles and bit rev tables are the same because it's the
same 512 pt fft everywhere.
The only static vars I've added are :
1x FFT config for all ffts.
struct CODEC2 lives as a static. it's persistent and I don't need more
than one instance.
The old FFT is inplace and where it is used there are input and output
complex float arrays or size 4k each, total 8 kbytes added to the stack.
I can't see anywhere that input fft array is used after the fft, so I
could get rid of one of those buffers saving 4kbytes on the stack,
that's significant.
the CMSIS FFT is also very very frugle on mem usage compared with KISS.
Overall the memory footprint I think would be 4k to 6 kbytes at least
down, not counting how much the kiss-fft eats the stac but it was rather
reentrant so.. yeah perhaps 8kbytes extra in hand, maybe more ???.
I've also changed a few structs to typedef stuct...... and named them
structname_t
I dislike old C struct syntax. I always do typedef struct {} xyz_t.
-g
On 16/09/2016 12:26 PM, Danilo Beuche wrote:
> Hi Glen,
>
>
> Am 16.09.2016 um 04:13 schrieb glen english:
>> Hi Danilo
>> Yeah, I guess being a very bare metal programmer from the old 128 byte
>> RAM days, , I dislike MALLOCs in embedded code on principal.
> Well. Although I also remember that are and in general do not like
> malloc being used by someone not knowing what she/he does,
> it does have its fair use cases.
>> However, because the heap usage would be deterministic, it should be
>> fairly safe.
> However, using stack is okay by me, makes it a little harder to monitor
> but the codec2 already uses a fair share of stack in some places.
> My concern was a migration to memory allocated statically which sits
> unused most of the time. This would be a true waste.
>> *******************************************************************************
>> Take a look at the memory management routine heap2.c in freertos.c
>> (in fact, there are heap1,2,3,4,5 .c - a few options... try heap4, also)
>> -this is a much smarter memory alloc and dealloc routine that is fairly
>> cheap.
>> much better than usual brain dead malloc.
>> ********************************************************************************
>> I'd recommend using that. It looks for blocks same size, existing used etc
>>
>> I would expect the same improvements on the F4 as the F7 using the CMSIS
>> library. The F7 is much faster on that sort of code.
>>
>> I only got rid of the FFT malloc stuff the huge stack additions are
>> still in there
>> and you could save 50% there ...
> Hope to see this soon. In order to not do double work here, we'll wait
> for your changes to materialize. The mcHF is now in a state where we can
> play with FreeDV. While this currently has some impact on the time
> available for task like the spectrum display, this is not critical since
> we can RX and TX without issues AFAIK.
>
> 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
