> All those malloc/free really make me nervous in a non-MMU allocation
environment.
...
> malloc/free are hugely black magic in a VM OS.
You're giving the software credit for more magic than is really there. The
only thing that a VM really gives the allocator is a way to ask for new
large memory segments when it runs out of heap. Most allocators never give
those segments back to the OS. So, getting more space for the heap is
usually just a call to mmap() on /dev/zero, usually asking for some number
of megabytes at a time which the allocator gets as one pointer and then
gets to break up into smaller pieces. It's quite unmagical.
Your complaint sounds like buffer overflow. Can you use valgrind on your
development system?
Thanks
Bruce
On Sun, Jun 10, 2018 at 5:30 AM, Steve <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
--
Bruce Perens K6BP - CEO, Legal Engineering
Standards committee chair, license review committee member, co-founder,
Open Source Initiative
President, Open Research Institute; Board Member, Fashion Freedom
Initiative.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
