<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class=""><div class="">Presumably defining those in mg_locals.h? Then I guess ovms.{h,cpp} needs our ExternalRamMalloc extended with ExternalRamCalloc and ExternalRamRealloc.</div><div class=""><br class=""></div><div class="">Or shall we just make a ov_malloc, ov_calloc, and ov_realloc, to be easier on the eyes?</div></div></div></div></blockquote><div class=""><br class=""></div>Let me know if you want me to do this first. Should be relatively simple as ESP-IDF provides equivalent functions.<div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25 Apr 2018, at 1:30 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Steve,<div class=""><br class=""></div><div class="">I see:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">#ifndef MG_MALLOC</div><div class="">#define MG_MALLOC malloc</div><div class="">#endif</div><div class=""><br class=""></div><div class="">#ifndef MG_CALLOC</div><div class="">#define MG_CALLOC calloc</div><div class="">#endif</div><div class=""><br class=""></div><div class="">#ifndef MG_REALLOC</div><div class="">#define MG_REALLOC realloc</div><div class="">#endif</div><div class=""><br class=""></div><div class="">#ifndef MG_FREE</div><div class="">#define MG_FREE free</div><div class="">#endif</div></div></blockquote><div class=""><div class=""><div class=""><br class=""></div><div class="">Presumably defining those in mg_locals.h? Then I guess ovms.{h,cpp} needs our ExternalRamMalloc extended with ExternalRamCalloc and ExternalRamRealloc.</div><div class=""><br class=""></div><div class="">Or shall we just make a ov_malloc, ov_calloc, and ov_realloc, to be easier on the eyes?</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 25 Apr 2018, at 1:20 PM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Mark,<br class=""><br class="">OK, I'll change mongoose to explicitly allocate from SPIRAM when<br class="">available. I won't be able to completely test it, though, since I<br class="">only have v3.0.<br class=""><br class=""> -- Steve<br class=""><br class="">On Wed, 25 Apr 2018, Mark Webb-Johnson wrote:<br class=""><br class=""><blockquote type="cite" class="">Steve,<br class=""><br class="">Because of things like this:<br class=""><br class=""><a href="https://github.com/espressif/esp-idf/issues/1492" class="">https://github.com/espressif/esp-idf/issues/1492</a> <<a href="https://github.com/espressif/esp-idf/issues/1492" class="">https://github.com/espressif/esp-idf/issues/1492</a>><br class=""><br class="">I tried setting the "SPI RAM access method" to "Make RAM allocatable using malloc() as well", and reducing "Maximum malloc() size, in bytes, to always put in internal memory" to 32 bytes, but get this crash on startup…<br class=""><br class="">Presumably that is esp_event_loop_init trying to create a FreeRTOS queue, and then objecting because it is not in internal RAM? It seems that the ESP IDF framework is not fully working with SPI RAM yet (due to inherent limitations). It would be better if the memory to be allocated must be internal, it is specifically allocated as internal (rather than just rely on a generic malloc).<br class=""><br class="">Last time I tried it (earlier this year), the ESP-IDF just simply didn’t work when that menuconfig option was set. When I fixed the above specific bug, it happened in another place.<br class=""><br class="">I know Espressif have been working on it, and perhaps they’ve fixed it now? This commit seems to try to address it in a generic way (at least for the freertos port stuff, if not for all the other libraries that we use):<br class=""><br class=""><a href="https://github.com/espressif/esp-idf/commit/16de6bff245dec5e63eee994f53a08252be720d4" class="">https://github.com/espressif/esp-idf/commit/16de6bff245dec5e63eee994f53a08252be720d4</a> <<a href="https://github.com/espressif/esp-idf/commit/16de6bff245dec5e63eee994f53a08252be720d4" class="">https://github.com/espressif/esp-idf/commit/16de6bff245dec5e63eee994f53a08252be720d4</a>><br class=""><br class="">IDF 3.0 has officially been released last night.<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 25 Apr 2018, at 4:40 AM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:<br class=""><br class="">We've been dancing around the external RAM allocation decision with<br class="">our own ExtenalRamMalloc() function and extensions to the C++ new<br class="">allocator to try SPIRAM first but then back off to internal memory if<br class="">that fails (presumably because of v3.0 hardware rather than because<br class="">all 4MB of SPIRAM is used up).<br class=""><br class="">Do we need all that? There is already a mechanism in the multi-heap<br class="">memory system for the defaut malloc to try allocating from SPIRAM for<br class="">any request with size larger than malloc_alwaysinternal_limit which<br class="">can be set dynamically with heap_caps_malloc_extmem_enable(). If the<br class="">allocation from SPIRAM fails (again, presumably only on v3.0 hardware)<br class="">then the allocation is retried without the MALLOC_CAP_SPIRAM<br class="">capability, which is just what our ExternalRamMalloc does.<br class=""><br class="">If there are only a few allocations such as stacks that must come from<br class="">internal memory, and if those allocations (in system code) already use<br class="">heap_caps_malloc(MALLOC_CAP_INTERNAL) to meet that requirement, then<br class="">we could probably just set malloc_alwaysinternal_limit to a small<br class="">number (perhaps 0) so that everything else comes from SPIRAM.<br class=""><br class="">I don't know if any of our application memory uses are sufficiently<br class="">sensitive to memory performance that we would want to ensure that the<br class="">memory is internal. My guess is that those would be few and therefore<br class="">it makes sense to take special action for them rather than for<br class="">everything else.<br class=""><br class="">For continued support of v3.0 hardware we could even test whether<br class="">SPIRAM is present and leave malloc_alwaysinternal_limit at its default<br class="">value of -1 if not.<br class=""><br class="">Opinions?<br class=""><br class=""> -- Steve<br class=""><br class="">On Mon, 23 Apr 2018, Mark Webb-Johnson wrote:<br class=""><br class=""><blockquote type="cite" class="">Michael,<br class=""><br class="">Do we need ovms_extram.h? Can we just put the namespace directly<br class="">into ovms.h (where all the other external ram allocation stuff is)?<br class=""><br class="">Regards, Mark<br class=""></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class=""></blockquote><br class=""></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>