Subject:        Re: [Freetel-codec2] more benching and thoughts
Date:   Fri, 16 Sep 2016 12:13:05 +1000
From:   glen english <g...@cortexrf.com.au>
Reply-To:       freetel-codec2@lists.sourceforge.net
To:     freetel-codec2@lists.sourceforge.net



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.

I'm similar, though now that we have 32kB, 64kB (or even more) RAM
in embedded chips, they're basically like the systems that malloc()
was initially built on :-)

I still don't trust C++ heap allocators in embedded applications, though.

However, because the heap usage would be deterministic, it should be
fairly safe.
I have a similar project; a 1200 baud modem + TNC stack built in a PSoC 5LP.
I use the Delta-Sigma ADC @ 9600s/s , 16-bits, the PSoC Digital Filter Block
to do bandpass heavy-lifting and frequency response correction for the ADC.
I use CMSIS-DSP for the rest of the DSP crunching required, and, wait for it,
wrap the whole thing in FreeRTOS (9.0.0 now). I use q31_t for all the DSP,
as long as I'm careful to avoid blowing out past the +/- 1.0 range, it's 
probably
every bit as good as single-precision floating point. The PSoC 5LP has a 
Cortex-M3,
I'm running it at 80MHz.

 My dynamic buffer implementation uses ...

*******************************************************************************
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

heap_4.c and, while I've never explicitly profiled it, I've never had a reason 
to
suspect the allocator is misbehaving. I commit 32KB to the heap and currently
never use more than about 3KB.
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 ...

Without knowing the details of this application (I'm new here), I am quite
impressed with the quality of CMSIS-DSP, particularly in terms of exploiting
the ARM extensions.

Cheers,
Dana


-glen


On 16/09/2016 12:06 PM, Danilo Beuche wrote:
> Hi Glen,
>
> nice, would be interesting to see how much the STM32F4 gains by use of
> CMSIS FFT routines.
>
> BTW, I am not sure, but I think you mentioned the removal of malloc as
> one of your changes. For us with the mcHF it would not be good to have
> the memory for FreeDV code statically allocated since FreeDV is just one
> operation mode of the mcHF, and we need the memory at other times for
> other stuff, especially since it really eats a lot of memory (in
> relation to the STM32F4 RAM sizes). Even half of it is still a lot.
>
> Looking forward to gain some more free cycles with your work.
>
> Regards,
> Danilo
>
>
> Am 16.09.2016 um 03:53 schrieb glen english:
>> Hi Danilo
>>
>> yeah, you have plenty in hand.
>>
>> OK so M7 and CMSIS FFT,  about 2 x speed (same clock) 7.74mS (1200bps)
>> for decode.
>>
>> On 16/09/2016 11:49 AM, Danilo Beuche wrote:
>>> H
>>>
>>> regarding the times @mcHF (STM32F4, 168Mhz) some clarifications: We
>>> measured 17.3ms per 40ms interval for the voice decode part only (this
>>> is only happening once the modem is synced) and roughly 5ms of
>>> fdmdv_demod per 20ms interval (happens all the time). Which gives us in
>>> total some 27ms per 40ms once synced. This is about 68% load.


------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to