<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
We should update our ESP-IDF anyway, got behind a bit. Maybe there
are also some filesystem fixes like a working fflush()? :)<br>
<br>
I second that internal RAM should be special, not external. But we
need to be careful about which components and objects must use
internal RAM.<br>
<br>
I've got a user report of a CAN affecting performance issue. I need
to check if that can be resolved by another task priority and/or CPU
core allocation scheme, but I think all low level processes should
generally remain in internal RAM. If time critical CAN TX get
delayed because buffers need to get paged in, that may lead to nasty
things.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 25.04.2018 um 01:57 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:276106C5-7EC3-49CB-AF9B-7D2A50893F92@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Steve,
<div class=""><br class="">
</div>
<div class="">Because of things like this:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><a
href="https://github.com/espressif/esp-idf/issues/1492"
class="" moz-do-not-send="true">https://github.com/espressif/esp-idf/issues/1492</a></div>
<div class=""><br class="">
</div>
<div class=""><i 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…</i></div>
<div class=""><i class=""><br class="">
</i></div>
<div class=""><i 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).</i></div>
</blockquote>
<div class="">
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>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):</div>
<div><br class="">
</div>
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class="">
<div><a
href="https://github.com/espressif/esp-idf/commit/16de6bff245dec5e63eee994f53a08252be720d4"
class="" moz-do-not-send="true">https://github.com/espressif/esp-idf/commit/16de6bff245dec5e63eee994f53a08252be720d4</a></div>
</div>
</blockquote>
<div class="">
<div><br class="">
</div>
<div>IDF 3.0 has officially been released last night.</div>
<div><br class="">
</div>
<div>Regards, Mark.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 25 Apr 2018, at 4:40 AM, Stephen Casner
<<a href="mailto:casner@acm.org" class=""
moz-do-not-send="true">casner@acm.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div 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=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>