Well, I'm upgrading the product from PSoC1 to PSoC5, and I'm STILL running out of ram and rom.

I've looked at thousands of compile .map files over my career, but haven't looked at a PSoC one yet.  So can you please help me out of my confusion a little?

First, I find the following:

Memory Configuration
Name             Origin             Length             Attributes
rom              0x00000000         0x00010000         xr
ram              0x1fffe000         0x00002000         xrw

The rom length of 0x10000 = 64kB matches the CY8C5566LTI-017 websheet at http://www.cypress.com/?mpn=CY8C5566LTI-017 as well as Table 12-1 of the datasheet linked therefrom.

HOWEVER, the ram length of 0x2000 = 2kB does NOT.  Both say the chip should have 16kB = 0x4000.  What am I missing?

Meanwhile, way too much of the rom is consumed already.  My application program is only a shell so far.  I figure it must be lots of code behind due to all the components I'm using in the TopDesign.  Looking through the .map, I find a couple sections CyPmHib... that consume nearly 5kB, nearly 8% of the total available.  There's also _svfprintf_r requiring over 5kB.  Now 16% enters my concern.  I commented out my use of hibernate, but only saved 0.4kB, not 5kB.  I'll analyze this further, so I'm not necessarily asking for a comment on it right now.  I'm mostly consumed about the ram size above.

Thanks.

Check your definitions of Stack and Heap in the system-view. These values are subtracted from total ram availlable and are put aside.

Having allocated 16% of availlable rom shouldn't be of concern for you. A zero (no code, no module) project will need about 5kB just for initializing the registers defining the hardware and the boot-process.

Using a library, for instance when working with floats, the code is only needed once regardless of the program. This is similar for other program parts even your own modularization will have a significant effect.

Happy coding

Bob.

 Thanks, Bob.  Follow-up questions below.

Yep, 0x1000=4kB for each Stack and Heap.  That's 8kB and half of all I've got.  Not acceptable.

I've spend decades minimizing microprocessor use of each, so I know how to do it in general.  But in specific, I would like some advice.  How do I know if I get an overflow?  I've reduced both to impossibly small 1 byte.  I do not get a compile error (the compiler is not analyzing the non-recursive call tree like Hi-Tech C does for a PIC), and my program actually runs.  This is in spite of local vars like "char msgtemp[64]" and an sprintf.  Miraculously, my simple code with RS-232 console continues to work.

And about stack vs heap.  I'm accustomed to local vars going on the stack.  Are they on the stack or in the heap?  (Maybe Hi-Tech C was assigning them in the heap?  I don't recall for certain.)  I'm not doing any malloc's, which definitely ought to use heap, but I don't know about the code behind the components.

Since stack and heap size of 1 doesn't give me any errors, I'm really concerned about how to reduce these specs!

Thanks again

You are using the Gnu CC environment which allocates (as usual) local vars on stack but does not check this afaik for overflow which has to be done by you with the usual strategy: Fill stack with known pattern and look after some time if pattern at top-of-stack still exists.

I have not come yet to a component source which uses the heap, but this is easier to check for overflow 'cause a pointer is returned with the value NULL. From time to time I run a search for malloc through the component files, but didn't find one yet. Seems that electronic engineers don't like linked lists (smile).

Bob

BTW The specs of the Gnu-compiler are openly published.

 Thanks.  I guess the gnu compiler, being free, has never done the obvious thing:  put in a compile flag to insert stack checking logic at the top of every function, and issue a stack overflow error if it happens!  I saw that stack memory fill method in some other post.  It made me harken back to the 1980's, argh!  I thought we had gotten past that...

The compile-flags for Gnu CC fill a couple of screens, one of them could be for stack checking but <i never searced for.

Bob

Sorry, heavy attach of dyslexia.

Must read "I searched"

Bob