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
