We've been dancing around the external RAM
allocation decision with
our own ExtenalRamMalloc() function and extensions to
the C++ new
allocator to try SPIRAM first but then back off to
internal memory if
that fails (presumably because of v3.0 hardware rather
than because
all 4MB of SPIRAM is used up).
Do we need all that? There is already a mechanism in
the multi-heap
memory system for the defaut malloc to try allocating
from SPIRAM for
any request with size larger than
malloc_alwaysinternal_limit which
can be set dynamically with
heap_caps_malloc_extmem_enable(). If the
allocation from SPIRAM fails (again, presumably only on
v3.0 hardware)
then the allocation is retried without the
MALLOC_CAP_SPIRAM
capability, which is just what our ExternalRamMalloc
does.
If there are only a few allocations such as stacks that
must come from
internal memory, and if those allocations (in system
code) already use
heap_caps_malloc(MALLOC_CAP_INTERNAL) to meet that
requirement, then
we could probably just set malloc_alwaysinternal_limit
to a small
number (perhaps 0) so that everything else comes from
SPIRAM.
I don't know if any of our application memory uses are
sufficiently
sensitive to memory performance that we would want to
ensure that the
memory is internal. My guess is that those would be few
and therefore
it makes sense to take special action for them rather
than for
everything else.
For continued support of v3.0 hardware we could even
test whether
SPIRAM is present and leave malloc_alwaysinternal_limit
at its default
value of -1 if not.
Opinions?
-- Steve
On Mon, 23 Apr 2018, Mark Webb-Johnson wrote:
Michael,
Do we need ovms_extram.h? Can we just put the
namespace directly
into ovms.h (where all the other external ram
allocation stuff is)?
Regards, Mark
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev