Static memory instead of the heap

Hello Everybody,

I started to work with mbedtls around two month ago so I am quite new in this area. I could sucessfully implement a http(s) client application on stmf7 microcontroller using lwip and mbedtls based on the examples provided in
https://www.st.com/en/embedded-software/stm32cubef7.html
The main difference between my application and the example in the Cube sw packet is that I don’t use FreeRTOS! Instead I use RAW-API of the lwip.

The client application works well with this example server:
https://httpd.apache.org/
I could send POST messages to the server and I got the answers from it.

I measured the memory consumption of the mbedtls which seems to me the following:
appr. 12 kByte static RAM
appr. 45 kByte dynamic RAM
These numbers are perfectly acceptable for me. At the moment I do not want to reduce memory consumption.

I am interested in avoiding using dynamic RAM so I want to use static memory instead of heap. I have found some discussions related to this topic but I could not find the solution which works for me.
Mainly I worked based on this article:
https://tls.mbed.org/kb/how-to/using-static-memory-instead-of-the-heap

I think I’ve done everything exactly as it is written in this article but I got compilation error which says that the mbedtls_calloc() function is unknown.

This article speaks about overloading this mbedtls_calloc() function but does not provide any example for how to do this:

Could anybody show me some examples for overloading mbedtls_calloc()? At all do I really need to overload mbedtls_calloc() function?

Thanks for any reply in advance:
Simon Kószó

Hi Simon,
While using static memory, have you consider using threading? If yes, How did you handle it?

Hi Shariful,

I do not use any operation system in my program and the task scheduler did not contain such funcionality. I have not considered using threading yet. I do not really understand how does it come into the picture? How does the timing and scheduling belongs to the memory handling?

Regards,
Simon