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

Groups > comp.arch.embedded > #28704

Dynamic allocation and newlib-nano

Show all headers | View raw

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?

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