If no "module memory" or "module tasks" command has been executed then the 32-bit RAM allocation that you see under NetMan task won't have been allocated, so for typical users there should still be plenty of free 32-bit RAM in case the system decides it needs some at a later time for some infrequent operation. If a memory diagnostic command is issued at a time when 32-bit RAM has been used for something else, the allocation will back off to 8-bit RAM which should work fine on v3.1 hardware. We developers might see a problem if memory diagnostics have been used and then some infrequent event needing 32-bit memory occurs. I implemented the 32-bit memory allocation for the v3.0 hardware since I couldn't afford to use all the 8-bit memory for diagnostics and I could make my code tolerate the lack of 8-bit access. I could make my code try SPIRAM first so that the 32-bit memory would be kept free on v3.1 hardware. That is, unless we consider the 32-bit memory otherwise wasted and want to keep as much SPIRAM available as we can. -- Steve On Fri, 11 May 2018, Michael Balzer wrote:
"module memory" doesn't show the allocation under "no task".
Up to now there have been no issues resulting from the low 32 bit RAM, the module has been running all day long, with all com channels and on multiple test drives & charges without a single crash or other problem. Looks really good.
I think I'll roll out the build on my server to get some field results.
Regards, Michael
Am 11.05.2018 um 17:13 schrieb Stephen Casner:
There are two possibilities:
1) The size of the 32-bit heap region may have been reduced because there is more code stored in RAM (perhaps for flash manipulation).
2) If the extra 32-bit RAM has been allocated from the heap, then "module memory" would show it under "no task".
-- Steve
On Fri, 11 May 2018, Michael Balzer wrote:
Update:
Am 11.05.2018 um 09:52 schrieb Michael Balzer:
According to the task monitor the new 32 bit allocations account to the NetMan task: Nope, the 32 bit usage of the NetMan task is the same as before. So the additional usage is outside the scope of our memory tracking, so must be a system component -- correct, Steve?
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26