Cypress Perform

Home > Design Support > Cypress Developer CommunityTM > Cypress Forums > PSoC® 1 > NO_FULL

Bookmark and Share
Cypress Developer CommunityTM
Forums | Videos | Blogs | Training | Rewards Program | Community Components



NO_FULL
Moderator:
ARVI

Post Reply
Follow this topic



NO_FULL

pran posted on 23 Feb 2013 3:41 AM PST
Top Contributor
26 Forum Posts



Re: NO_FULL_USE_I/O

pran posted on 23 Feb 2013 03:45 AM PST
Top Contributor
26 Forum Posts

I am Using CY8C20434 for my project , it has 28 I/O(sensor) capacity but when i use more than 11 sensor RAM get full.

Error occures, Why is it so?

Pran.



Re: NO_FULL

danaaknight posted on 23 Feb 2013 04:24 AM PST
Top Contributor
1773 Forum Posts

If you post project Forum can take a look at it. A schematic

would also be helpful.

 

There are a number of techniques to minimize stack usage,

which is in RAM, and FLASH usage.

 

Regards, Dana.



Re: NO_FULL

pran posted on 24 Feb 2013 10:58 PM PST
Top Contributor
26 Forum Posts

@Dana

Can u suggest me any document or user guide regarding RAM usage or Flash usage technigues.  It will help me lot.

Regards, Pran



Re: NO_FULL

Bob Marlowe posted on 24 Feb 2013 02:08 AM PST
Top Contributor
1768 Forum Posts

@Pran

When you go through the CapSense datasheet you will see that each button, slider or whatever widget you use needs a bit of Ram. Your device has got 512 byte SRam including the required stack which makes me think that you might have forgotten to turn-on "Enable Paging" in the Project -> Options dialog.

I did not go through the datasheet precisely, but if looked like at first glance that it needs something like 11 bytes for each sensor which with 28 sensors would come out to 300 bytes.

 

Bob



Re: NO_FULL

danaaknight posted on 24 Feb 2013 02:13 AM PST
Top Contributor
1773 Forum Posts

This might help -

 

http://www.cypress.com/?rID=45644

 

and this -

 

1 - If any float math minimize the number of lines you do divides, if possible convert
to multiplies. Convert float to integer math where possible. Pay attention to factoring
of expressions, possible operation reduction, hence code reduction may result.

2 - Lines with function calls, minimize f(g()) compound typed expressions.

3 - Make sure you only use a variable type no larger than needed.

4 - Use unsigned variables wherever possible.

5 - Watchout for structures with mixed const and ram pointers within them,
some compilers choke on this.

6 - If you are heavy on Flash, light on RAM use, convert routines to RAM based
wherever possible.

7 - Try test cases of looping structures, to see what affects code size generation.

8 - Examine .lst file for code that looks wacky in bytes used, understand what
compiler did, and consider rewrite.

9 - Use inline ASM where .lst file C generation looks excessive.

10 - Look at module reuse, sharing, dual purpose, to eliminate # modules 
needed, like counters/timers....Also look at data sheets of modules that could
serve function needed, and compare ROM/RAM requirements needed. Optimize
global HW, like clocks VC1/2/3/Sleep, to eliminate need for other timer/counters.
Use register routing control to "share" module from one task to another, one pin
to another.

11 - Extended library, functions within them are written to be perfectly general,
hence larger code size, you may be able to write one with less code needed for
your specific requirements that result in smaller code size.

12 – Look for approximations to compute transcendental functions if used.

13 - Although no longer supported by HiTech or Cypress, the HiTech Pro compiler
yielded on first try ~ 40% code reduction in my design when I first converted
to it. Then the prior comments yielded another 4 K later in design as I was up
against 32 K Flash limitation.

14 - Some compilers have a setting to optimize code size or speed, the latter
prone to larger code size. Also look at compiler vendors web site for ap notes
and suggestions on optimization, compilers from different vendors behave and
optimize  differently.

15 - const data, strings, etc.., look for ability to reuse common string mnemonics,
text.

16 - Pointer usage can lessen code size, see url's below. Look for function calls
passing longs as value vs pointer, convert to latter. Compiler has to copy all these,
if not referenced. Do not pass longs or floats as values, keep always in mind native machine size.

17 - Most compilers will optimize when indexes, pointers, a power of 2, or divides,
divide becomes a shift.

18 - Look at how linker distributed code and data segments, sometimes you can discover
a poor decision by linker and force code/data into certain psects using pragma constructs,
thereby minimizing wasted ROM space.

19 – When you debug generally you want to turn off optimization, as compiler/linker will
remove code and make jumps that do not make “sense” but are the result of optimization.
When you are up to Flash boundary you may not be able to turn it off, otherwise
application will not load. Keep this in mind, that  your debug strategy may have to change.
I also found if using ICE Cube that debugger may no longer report “watch” variables, this
occurred at ~ 31.5K bytes. In either case you may want to comment out large code sections
to effectively debug.

20 – f() calls take overhead, if you only call a f() once you might eliminate it as a f() call and
place code inline.

21 – Look for f() opportunities, wherever you are coding and repeating similar  operations.
This is obvious, but sometimes missed.

22 – Check compiler on macros, to see if they are being optimized or just being used inline
using more code space vs a f() call solution.

23 – Examine compiler/linker parameter control. For example in HiTech there is the AUTOBANK
setting that controls where local variables are stored, in my case setting to 1 lowered code size by
~ 250 bytes. READ the MANUAL !

24 – Use inline variable declarations, vs pre declaration (compiler dependent) -

    This        void dosomething ( void  ) {

                for (  unsigned char I = 0;…..
            }

    Not This    void dosomething ( void  ) {

            Unsigned char I = 0;

                for (  I = 0;…..
            }

Some help -


[url]http://www.codeproject.com/Articles/6154/Writing-Efficient-C-and-C-Code-Optimization[/url]

[url]http://www.eventhelix.com/realtimemantra/basics/optimizingcandcppcode.htm[/url]

[url]http://www.azillionmonkeys.com/qed/optimize.html[/url]


By using these techniques I was able to regain ~ 4K Bytes of code space in a 32K design, which
I promptly then used up again :(

Regards, Dana.
 



Re: NO_FULL

pran posted on 24 Feb 2013 02:55 AM PST
Top Contributor
26 Forum Posts
Thank you very much to both. Initially my consideration is that code size doesn't affect that much in memory optimization. Let me compress the code. Regards, Pran.




ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Spec No: None; Sunset Owner: GRAA; Secondary Owner: RAIK; Sunset Date: 01/01/20