Heap space

[f.h-f.s.]

Hello all,

I'm trying to combine wifi, ble, openssl and a library that needs a tls connection.
Everything works fine without ble enabled.
With ble enabled I don't have enough heap space to create a ssl object.
I figure from calling a few esp_get_free_heap_size() that my program + the ssl connection uses about 55kb.
Wifi uses about ~40kB, Ble also uses about ~40kB.

I end up with 20kB free heap space, which is about 10~20kB short of what I need.

I only use ble for scanning advertisements, so I was thinking I might cut some of the bt functionality. Maybe cut some of the stack size.

My question is what is the easiest way to create some heap space?
What can I cut in Ble, i'm looking at the "bt/bluedroid/include/bt_target.h" which enables some functionality if i'm not mistaken.
"bt/bluedroid/osi/include/thread.h" defines the stack size for btu,btc,hci_host and hci_h4. Don't really have a clue what btc and btu do, any documentation?
Can I move stuff to the flash? if so how?

I'd love some suggestions. trial and error is so slow.

Thanks!

[WiFive]

Memory management on an embedded system feels like an artform sometimes. Hopefully we will get some good fine grained options to increase available memory as right now it seems like there are only blunt instruments available. And we lost 2k again recently to the event handler task stack

Well there's always the new PSRAM 4MB chip that is coming soon. I hope that will only be necessary in extreme cases.

As for TLS connections,

Code: Select all

config MBEDTLS_SSL_MAX_CONTENT_LEN

Maximum TLS message length (in bytes) supported by mbedTLS.

16384 is the default and this value is required to comply
fully with TLS standards.

However you can set a lower value in order to save RAM. This
is safe if the other end of the connection supports Maximum
Fragment Length Negotiation Extension (max_fragment_length,
see RFC6066) or you know for certain that it will never send a
message longer than a certain number of bytes.

is the easiest way to reduce memory usage. Even if you don't control the server a lot of these IOT use cases are going to have relatively small message sizes.

[f.h-f.s.]

What a way to go WiFive!
That just saved me like 16kB! by just cutting the size in half.
Thanks a bunch!

[WiFive]

No problem. We really need a way to specify tx/rx buffer sizes on a per connection basis because pulling a firmware update and pushing an Mqtt message are going to have very different requirements.

[f.h-f.s.]

We can create multiple program partitions on the flash right? Doesn't that mean you can get a message "update rdy" boot into another program for updating ota with a different mbedtls content length.

I tried cutting bt functionality btw, not much success. I think i gained about 2kB cutting a few things. Messing with the stack size of the bt tasks didn't really help either.

[WiFive]

Yes that could be a workaround for that case, but not very flexible or elegant as a general solution.