Page 1 of 1
zalloc not more supported in esp-idf was there a change?
Posted: Tue Sep 27, 2016 1:23 am
by rudi ;-)
hi guys,
have a small problem with zalloc
Code: Select all
char *recv_buf = (char *)zalloc(512);
in ESP31 RTOS compile without problems
is there a change in esp-idf?
btw:
lwip/mem.h
Code: Select all
#ifndef mem_zalloc
#define mem_zalloc(s) ({const char *file = mem_debug_file; pvPortZalloc(s, file, __LINE__);})
best wishes
rudi
Re: zalloc not more supported in esp-idf was there a change?
Posted: Tue Sep 27, 2016 3:46 am
by kolban
This is a wild guess ... but if ESP-IDF plans to delegate management to FreeRTOS then by the FreeRTOS docs, it appears we should use pvPortMalloc() to allocate memory and vPortFree() to free memory. It is likely pvPortZalloc() is the same as pvPortMalloc() with zero value initialization.
Re: zalloc not more supported in esp-idf was there a change?
Posted: Tue Sep 27, 2016 5:17 am
by ESP_igrr
You can use calloc, which is part of C standard library.
Re: zalloc not more supported in esp-idf was there a change?
Posted: Tue Sep 27, 2016 9:35 am
by ESP_Sprite
kolban: Actually, malloc, calloc etc are provided by newlib (and the current esp_idf configures them to basically use the freertos alloc structs). I don't think there's any danger in using them instead of the FreeRTOS constructs.
Re: zalloc not more supported in esp-idf was there a change?
Posted: Tue Sep 27, 2016 5:25 pm
by kolban
Would it be possible to describe the relationship between newlib and the other components? For example, I was reading about newlib and think this is what is meant:
http://www.sourceware.org/newlib/
Are we saying that the functions exposed by newlib can be safely used in an ESP32 ESP-IDF environment? Are there restrictions or caveats?
I see in github that newlib is distributed in binary form:
https://github.com/espressif/esp-idf/tr ... newlib/lib
Is there a reason the source is not available?
Re: zalloc not more supported in esp-idf was there a change?
Posted: Wed Sep 28, 2016 1:55 am
by ESP_Sprite
Newlib indeed is the newlib you point at (or a version that has been lightly modified to compile on Xtensa, not sure, not much difference in how it works.)
We distribute newlib in binary form because the bulk of it actually is integrated in ROM. We could also distribute the bit that's linked into the flash app in source form (and maybe we will, if there's demand for it; there are no secrets there afaik) but it's not that useful because it has to be compiled with exactly the same compiler / flags / ... as the Newlib in ROM in order to work. Compiling it from source as we do with the rest of esp-idf would potentially introduce bugs when people mess with the esp-idf configuration or compiler and the interface would become incompatible.