Hi Steve,
For the FreeDV 1600 port we have the same code compiling and running
nicely on a variety of CPUs, including the stm32. Some refactoring was
required, but the stm32 version runs happily with several init-time
mallocs. So I feel it's possible to port other modes, without extensive
platform specific changes.
The approach I took for the stm32 port of FreeDV 1600 port was a series
of unit tests, including comparisons to the x86 code using a
semi-hosting (printf/fread/fwrite) system. Carefully verify modules of
code - well before attempting integration.
Yes, we will need to be careful with run time memory for a 700D port.
First step is to characteristic that on an easy to use platform like x86.
Cheers,
David
On 10/06/18 22:00, Steve wrote:
All those malloc/free really make me nervous in a non-MMU allocation
environment.
In my own testing, I have found that large automatic arrays (at the
top of the function), and malloc arrays (at the top of a function or
initialization section) create problems.
My solution is the old tactic of putting everything in the BSS. This
is memory that really does get allocated (not some virtual maybe
allocation) and it gets set to zero for free when you turn the power
on. On top of that, the heap and stack don't crash into it.
For example I was getting a popping sound on my sm1000 project in the
receive audio. So I tried changing the automatic variable to a
malloc/free and the popping got worse. I then changed it to BSS and
the popping was gone.
This, even though the memory is set to zero in a for/next loop. I
don't understand the popping unless the firmware interrupts are
interfering with the function execution time.
The newer modems are using two codec frames (four for 700D), which
mean they are rather large allocations compared to 1600 mode, so maybe
the new lengths and the interrupt timing are not optimized.
The completely undesirable part of my method, is it can't be aligned
back into the master code. That code is designed around malloc/free.
malloc/free are hugely black magic in a VM OS. Maybe too simplistic in
OS/MMU free boards with 1 kHz interrupts.
Maybe we need some critical/non-critical markers around sections of
code. Shut the interrupts off, do your memory allocation and
initialization, then turn the interrupts back on.
Just thinking...
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
