[Ovmsdev] Moving stuff to SPI RAM

[Mark Webb-Johnson]

I’ve committed (and pushed) an experimental extension to allow C++ objects to be optionally moved to SPI RAM.

The code is in ovms.h, so should be easily accessible to everything. It is pretty simple:

We have a new class ‘ExternalRamAllocated’. That does nothing except override the new and new[] operators.

Those operators try to malloc from SPI RAM first. If that doesn’t succeed then they fall back to standard internal RAM.

The definition of a C++ class can then be changed to make it “: public ExternalRamAllocated”. Once that is done, any objects of that class allocated will try to be placed in external (SPI) RAM.

For other malloc uses, a general purpose 'void* ExternalRamMalloc(std::size_t sz)’ function is also provided.

To test this, I’ve made a one line change to the OvmsCommand class:

-class OvmsCommand
+class OvmsCommand : public ExternalRamAllocated

Here is what the memory usage looks like:

With SPI RAM disabled (in menuconfig):

Free 8-bit 120844/284304, 32-bit 30508/57680, SPIRAM 0/0
--Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
no task            5312      0      0      0      +5312     +0     +0     +0
esp_timer         52328      0    644      0     +52328     +0   +644     +0
main              16448      0      0      0     +16448     +0     +0     +0
ipc0              11096      0      0      0     +11096     +0     +0     +0
Housekeeping      40576   5120      0      0     +40576  +5120     +0     +0
tiT                 128      0      0      0       +128     +0     +0     +0
Tmr Svc             884   6444      0      0       +884  +6444     +0     +0
ipc1                 12      0      0      0        +12     +0     +0     +0
AsyncConsole         20      0  26404      0        +20     +0 +26404     +0

Without deriving OvmsCommand from ExternalRamAllocated:

Free 8-bit 119240/282436, 32-bit 424/27596, SPIRAM 4193924/4194252
--Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
tiT                   0      0      0    128         +0     +0     +0   +128
Housekeeping      40564   5120      0     12     +40564  +5120     +0    +12
no task            5348      0      0      0      +5348     +0     +0     +0
esp_timer         52328      0    644      0     +52328     +0   +644     +0
main              16448      0      0      0     +16448     +0     +0     +0
ipc0              11096      0      0      0     +11096     +0     +0     +0
ipc1                 12      0      0      0        +12     +0     +0     +0
Tmr Svc             884   6444      0      0       +884  +6444     +0     +0
AsyncConsole         20      0  26404      0        +20     +0 +26404     +0

After deriving OvmsCommand from ExternalRamAllocated:

OVMS > module memory
Free 8-bit 152308/282432, 32-bit 424/27596, SPIRAM 4160852/4194252
--Task--     Total DRAM D/IRAM   IRAM SPIRAM   +/- DRAM D/IRAM   IRAM SPIRAM
esp_timer         31664      0    644  20664     +31664     +0   +644 +20664
tiT                   0      0      0    128         +0     +0     +0   +128
Housekeeping      39636      0      0   6060     +39636     +0     +0  +6060
no task            5348      0      0      0      +5348     +0     +0     +0
main              16448      0      0      0     +16448     +0     +0     +0
ipc0              11096      0      0      0     +11096     +0     +0     +0
ipc1                 12      0      0      0        +12     +0     +0     +0
Tmr Svc            7328      0      0      0      +7328     +0     +0     +0
AsyncConsole         20      0  26404      0        +20     +0 +26404     +0

The advantage of SPI RAM is obvious. 30KB of internal RAM saved with just one line changed in a header file. Most of our other objects like that (metrics, configs, etc) could be equally easily moved to SPI RAM. We can make the decision on a class-by-class basis.

I think this is a pretty good solution. It puts the onus of the decision of whether to put into SPI RAM into the object itself (as presumably the object knows best whether it can actually be put in SPI RAM). It is also extremely simple to define that.

But, it is an experiment. Please let me know what you think.

Regards, Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180216/2c125857/attachment.htm>