- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's consumed by srand() / mathematical group
Flash used: 1280 of 32768 bytes (3.9%).
SRAM used: 228 of 4096 bytes (5.6%).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@PSoC73:
Yes, of course I know that srand() is consuming my sram! (Sometimes I may look stupid, but I am not!)
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.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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%).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am confusing original SRAM consumption as 2,400bytes.
Optimizing and DEGUG flag will no help for it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The "Linux" conundrum, GCC, public tools vs commercial tools.
In charge of ones own destiny, or not.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Regards,
Rave