[Ovmsdev] Working on ESP-IDF5 + Have a question about ovms_module 'Name'

Michael Geddes frog at bunyip.wheelycreek.net
Fri Jan 26 16:23:48 HKT 2024


Oh damn, that is both unfortunate and sad that he is no longer with us.

The high-bit  does seem to almost have a usage, but I'm just not seeing it
quite and there's possibly a bug if it does?
It seems that once you call the   command 'modules task stack'
* this calls get_tasks() which calls populate()
* which then marks all the  tasks in the list with * and high-bit and then
the reloads the existing tasks and names which overrides both * and
high_bit()
* The high bit (and a long task name) will cause the zero() function to not
remove the entry from the list.
* module memory   and  module leaks  commands both call
changes->transfer()  which calls zero(Task) for every item in HeapTotals
that has zero 'after' value for DRAM, D_IRAM and SPIRAM.

So this is really affecting only module commands output.  I certainly think
that the 'and a long task name' part is a weird mistake.  I guess we can
see what we see.
This was all just trying to make it readable and fix the memory access
crashes I was getting when I added in some extra methods required by the
compiler.

//.ichael

On Fri, 26 Jan 2024 at 09:34, Mark Webb-Johnson <mark at webb-johnson.net>
wrote:

> Michael,
>
> Unfortunately, Steve passed away in 2022 so is unlikely to reply :-(
>
> He did work on some of the lower level and more complex parts of OVMS, as
> well as the command processing framework, and is sorely missed.
>
> I can’t help much with the code you are working on, other than to ask if
> this functionality is still required in the v5 IDF framework? A lot of
> stuff we did back then was to address inadequacies in the very new early
> buggy frameworks coming out of Espressif for the just released ESP-32.
>
> Regards, Mark.
>
>
>
> > On 26 Jan 2024, at 9:23 AM, Michael Geddes <frog at bunyip.wheelycreek.net>
> wrote:
> >
> > Does this help? Any thoughts on what this was meant to do ? I've CCd
> Stephen with a hope he might chip in?
> >
> > //.
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20240126/1def656f/attachment.htm>


More information about the OvmsDev mailing list