It's consumed by srand() / mathematical group
Flash used: 1280 of 32768 bytes (3.9%).
SRAM used: 228 of 4096 bytes (5.6%).
The point is that there is no math routine (not even srand()) that may take 1000 bytes of precious sram for nothing!
This is obviously a(nother) library error with the m0 libs. And: Yes, I already filed a MyCase and will keep you all informed.
I see there is no math routines except srand.
But, I think srand come with other math group routines.
Maybe these are consume sram, even if you didn use.
It is no help.
When refine the project setting
Optimize for SIZE and turn off DEBUG
sram consumption can reduce 2,400 to 1,300 byte.
Flash used: 2216 of 32768 bytes (6.8%).
SRAM used: 1300 of 4096 bytes (31.7%).
I must be blind, did not Bob originally state his SRAM consumption was 1300
bytes, are your last numbers incorrect PSOc73 ? They show only FLASH change.
Oh, that was wrong
I am confusing original SRAM consumption as 2,400bytes.
Optimizing and DEGUG flag will no help for it.
I dug a bit further into that matter and evovled this to be a library problem.
When a library function is used, rather often a global returncode is set named "errno" which allows for analyzing the reason of ailure. This is commonly used for OSses and since GCC libraries are used for this, "errno.h" is included which in turn loads a library "reentrant.h" which allocates data-structures of 1kbyte size just to maintain multitask- and context switching which so far would be a bit too much for a PSoC4.
The "Linux" conundrum, GCC, public tools vs commercial tools.
In charge of ones own destiny, or not.
Cypress has resolved this issue in their upcoming version of Creator i.e Creator 3.0. This will be released in October, 13.
I got the beta version of Creator and this issue is no more available in Creator. They have updated the compiler of PSoC4 to later releases in Creator 3.0.