Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28706

Re: Dynamic allocation and newlib-nano

Show all headers | View raw

Il 27/06/2019 13:42, upsidedown@downunder.com ha scritto:
> On Thu, 27 Jun 2019 13:08:20 +0200, pozz <pozzugno@gmail.com> wrote:
> 
>> I normally don't use dynamic allocation in embedded projects, however
>> there are situations where this isn't possible.
>>
>> I'm working on a project with LPC1768 Cortex-M3 MCU that features
>> 32kB+32kB RAM. I'm using lwip+mbedTLS to make a TLS connection to AWS
>> IoT Core through Ethernet.
>>
>> After a precise allocation of data blocks (incoming Ethernet packets,
>> outgoing packets and so on), it seems working. However I'm using dynamic
>> allocation, mainly for outgoing packets: when some application (MQTT,
>> DNS client, ...) wants to transmit, lwip requests some space from the heap.
>>
>> lwip can be configured to use a set of memory pools of different sizes
>> to avoid dynamic allocation, but it's very difficult to configure.
>> During execution I saw allocation requests of very different sizes: 5-10
>> bytes, 50-100 bytes, 800 bytes, 1500 bytes.
>>
>> However the dynamic allocation algorithm appears very strange to me. I
>> expected that malloc() returns always the start of the heap if the heap
>> is completely free. It is so at the beginning, however when some
>> allocations and deallocations happen, even if the heap is completely
>> deallocated (all the allocations were freed), a new allocation doesn't
>> return the start of the heap.
>> How to explain this behaviour?
> 
> malloc() needs to store the actual allocated size (user requested
> size+possible align to word/longword boundary), so that free() can
> deallocate the total amount allocated. In addition dynamic allocation
> is often allocated as linked lists so some descriptors may be used.
> One convenient place to store this auxiliary data is at the top of the
> heap and only then add the user requested buffer, thus the user
> receiver never starts at the start of heap, but after this descriptor.

Yes, I know.  When I wrote that malloc() returns a different address 
than the start of the heap, I meant it is *very* different.

In other words, if the heap is at 0x1000, after many 
allocations/deallocations, when the heap is again completely free, 
malloc() returns 0x1100, 256 bytes from the start of the heap.

> 
>>
>> I noticed my allocation pattern is very simple and, after 1-5
>> allocations, there are other 1-5 deallocations and I eventually have a
>> completely free heap, when all the outgoing packets are serially shifted
>> out and/or acked from the remote side.
>>
>> For example:
>> - malloc(3)=addr1
>> - free(addr1)   -> free heap
>> - malloc(5)=addr2
>> - malloc(60)=add3
>> - free(addr2)
>> - free(addr3)   -> free heap
>> - malloc(800)=addr4
>> - malloc(5)=addr5
>> - malloc(32)=addr6
>> - free(addr5)
>> - malloc(80)=addr7
>> - free(addr6)
>> - free(addr7)
>> - free(addr4)   -> free heap
>>
>> With this pattern, I think I can simplify the allocation algorithm so
>> that it returns always the start of the heap when it is completely free
>> and reduce fragmentation of complex algorithm.
> 

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-27 13:08 +0200
  Re: Dynamic allocation and newlib-nano upsidedown@downunder.com - 2019-06-27 14:42 +0300
    Re: Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-27 15:59 +0200
      Re: Dynamic allocation and newlib-nano Niklas Holsti <niklas.holsti@tidorum.invalid> - 2019-06-27 17:47 +0300
        Re: Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-27 18:37 +0200
          Re: Dynamic allocation and newlib-nano Niklas Holsti <niklas.holsti@tidorum.invalid> - 2019-06-27 21:23 +0300
            Re: Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-28 11:38 +0200
        Re: Dynamic allocation and newlib-nano George Neuner <gneuner2@comcast.net> - 2019-06-27 17:02 -0400
  Re: Dynamic allocation and newlib-nano Joe Chisolm <jchisolm6@earthlink.net> - 2019-06-27 12:09 -0500
  Re: Dynamic allocation and newlib-nano Paul Rubin <no.email@nospam.invalid> - 2019-06-27 14:23 -0700
    Re: Dynamic allocation and newlib-nano pozz <pozzugno@gmail.com> - 2019-06-28 08:42 +0200

csiph-web