[Ovmsdev] esp-idf release 3.0 / master
dexter at expeedo.de
Sat May 12 23:50:20 HKT 2018
Since my rollout of the build with the current esp-idf master yesterday, 8 users have installed the new release.
So far, no issues have been reported.
Crashes still occur, I just again had the one in mbuf_insert() (issue #120).
But I don't think the new release has a RAM issue that needs to be solved.
Am 11.05.2018 um 21:39 schrieb Stephen Casner:
> 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
> 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.
>> 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:
>>>> 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?
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
More information about the OvmsDev