FLASH OVERFLOW

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 hi...

   

     i am using PSoC3- cy8c38466, which consists of 64 KB flash memory to store my code......but, my project code is too big to fit into this 64 KB flash......

   

Actually my flash memory is almost full, but my project is not yet completed....still it may need approximately 10 KB......so, can anyone suggest the solution.......

   

Is it possible to interface memory externally, to store rest of my code........? If it is, please suggest  the way to do it so that my code should not break

   

 

   

Thank you

0 Likes
1 Solution
Anonymous
Not applicable

 Hello Sivananda,

   

   
    
      Have you tried playing around with the compiler optimization levels in the Build Settings of the project?    
   

View solution in original post

0 Likes
6 Replies
Anonymous
Not applicable

 Hello Sivananda,

   

   
    
      Have you tried playing around with the compiler optimization levels in the Build Settings of the project?    
   
0 Likes
Anonymous
Not applicable

@Avagadro 

   

my optimization levels has a value from 0 to 11...what does it mean?

0 Likes
Anonymous
Not applicable

 yes......it is optimized....

   

@Avagadro....Thank you

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

There is an appnote for PSoC3 showing a lot of tricks to decrease the amount of code when accessing vars

   

Have a look here : http://www.cypress.com/?rID=40986 

   

Sometimes it is effective to do a re-structuring of the code, extracting similar code-blocks into general functions called from different places. The resulting .map file can help you to show where you "burn" most of your code to find targets for promising reduction.

   

 

   

Experiences have shown that together with a restructure the code gets "better" in terms of readability and efficiency.

   

 

   

When really *ALL* fails, go for a PSoC5 solution.

   

 

   

Happy coding

   

Bob

Anonymous
Not applicable

You can refer to this KB article to understand the differences between various levels of Optimization - http://www.cypress.com/?id=4&rID=38515.

   

Or you can refer to KEIL's KB article as well - http://www.keil.com/support/man/docs/c51/c51_optimize.htm.

ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

I used this on PSOC 1, much would also apply to PSOC 3 -

   

 

   

              

   

These helped me in a similar experience -

   

 

   

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 -

   

 

   

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

   

 

   

http://www.eventhelix.com/realtimemantra/basics/optimizingcandcppcode.htm

   

 

   

http://www.azillionmonkeys.com/qed/optimize.html

   

 

   

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.