tomicdesu
Well-known member
My current project, nearing "final" release, has used pretty much all of the megabyte of memory. For a few weeks I'm having very sporadic, mostly unrepeatable errors in execution that I've been assuming were my bad code, but now I'm thinking, after narrowing it down behaviorally, that it's a memory, specifically stack, issue.
Here's the output of meminfo(), from helpful thread https://forum.pjrc.com/index.php?threads/how-to-display-free-ram.33443/, right before loop execution. Is this me about to run out of stack space?
The code is structured as a series of event loops, Wiring taken seriously, a dozen task-loops, each one a C++ object, each task's loop() called in turn, with message passing done by calling public methods through a dispatcher. So it's moderately stack heavy. No code in any task loop blocks, except SD library read and write.
I do use malloc, but only in each task loop's setup(), one time, and it's never released, so it's analogous to static memory allocation. This meminfo() output is run after all initialization is done, including all mallocs.
I've barely read about PSRAM, the solder-on-able serial memory. I'd rather not... does that last line imply I have 262K of RAM I'm not using now? The big num to it's left is 256MB of course.
There are a few places where I'm putting scratch buffers on the heap, as arrays local to a subroutine. I'll look at making those static and possibly sharing them if they're sizeable enough, but I doubt I have even 256 byte buffs there, but it's best to look..
I'm trying to avoid old-fashioned memory-saving techniques, that gets ugly fast.
I got that meminfo() func from that thread above (https://forum.pjrc.com/index.php?threads/how-to-display-free-ram.33443/) months ago; re-reading it is now mentioned some CrashReport thing and it's missing. Lol I wonder if I have enough memory left to run it!
Here's the output of meminfo(), from helpful thread https://forum.pjrc.com/index.php?threads/how-to-display-free-ram.33443/, right before loop execution. Is this me about to run out of stack space?
Code:
_stext 00000000
_etext 00025ed8 +155352b
_sdata 20000000
_edata 2000aac0 +43712b
_sbss 2000aac0
_ebss 20052de0 +295712b
curr stack 20057f68 +20872b
_estack 20058000 +152b
_heap_start 202772a0
__brkval 20278000 +3424b
_heap_end 20280000 +32768b
_extram_start 70000000
_extram_end 70000000 +0b
<ITCM> 00000000 .. 00027fff
<DTCM> 20000000 .. 20057fff
<RAM> 20200000 .. 2027ffff
<FLASH> 60000000 .. 607fffff
<PSRAM> 70000000 .. 7fffffff
avail STACK 20872 b 20 kb
avail HEAP 32768 b 32 kb
avail PSRAM 268435456 b 262144 kbThe code is structured as a series of event loops, Wiring taken seriously, a dozen task-loops, each one a C++ object, each task's loop() called in turn, with message passing done by calling public methods through a dispatcher. So it's moderately stack heavy. No code in any task loop blocks, except SD library read and write.
I do use malloc, but only in each task loop's setup(), one time, and it's never released, so it's analogous to static memory allocation. This meminfo() output is run after all initialization is done, including all mallocs.
I've barely read about PSRAM, the solder-on-able serial memory. I'd rather not... does that last line imply I have 262K of RAM I'm not using now? The big num to it's left is 256MB of course.
There are a few places where I'm putting scratch buffers on the heap, as arrays local to a subroutine. I'll look at making those static and possibly sharing them if they're sizeable enough, but I doubt I have even 256 byte buffs there, but it's best to look..
I'm trying to avoid old-fashioned memory-saving techniques, that gets ugly fast.
I got that meminfo() func from that thread above (https://forum.pjrc.com/index.php?threads/how-to-display-free-ram.33443/) months ago; re-reading it is now mentioned some CrashReport thing and it's missing. Lol I wonder if I have enough memory left to run it!