[Ovmsdev] esp-idf release 3.0 / master

[Michael Balzer]

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.

Regards,
Michael


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
> 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 at 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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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