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@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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev