--- In l..., "alexander_ribero" wrote: >
> In Keil uVision, go to "Options for Target", select the C/C++ tab and check
the "One ELF Section per Function" checkbox.
>
Sounds like a good suggestion. I was interested to know if there were any
'catches' e.g. if you were using any 'clever tricks' to
access functions indirectly. While looking into this, a useful document showed
up:
Application Note 202: "Getting the Best Optimized Code for your Embedded
Application"
Reply by alexander_ribero●January 8, 20102010-01-08
Hi:
In Keil uVision, go to "Options for Target", select the C/C++ tab and check the
"One ELF Section per Function" checkbox.
Then, go to Linker tab, and write "--remove" in the Misc controls textbox.
Compile and check the size again.
These options prevent the linker to add functions that are not used in the code.
By default Keil linker adds every function that is in a module (.c file) even if
it not used anywhere.
Let us know if this helps reducing the program size.
Regards,
Alex
--- In l..., "Graham Jones" wrote: >
> Thanks to the many responders, you have been a great help. Here are my
findings and a couple of questions.
>
> Code Sizes with Optimizations Results (CrossWorks)
> --------------
> ARM DEBUG + OPT LEVEL 1 34,940
> ARM DEBUG + OPT LEVEL 2 34,716
> ARM DEBUG + OPT LEVEL 3 34,440
> ARM DEBUG + OPT FOR SIZE 34,440
> ....optimizations won't solve my problem.
>
> Code Sizes for Various Builds Results (CrossWorks)
> --------------
> ARM DEBUG 36,116
> ARM RELEASE 27,708
> THUMB FLASH DEBUG 27,872
> THUMB FLASH RELEASE 21,416
> .....thumb *will* solve my problem
>
> Memory Map
> ----------
> I dumped the memory map into Excel and sorted by code size. I have pasted it
inline below. I think it tells me to work on "SetupNewGame" and "PlayGame".
The former I can definitely optimize.
>
> The calls FPCONV, FPDIV, FPMUL, FPADD, I assume are floating point operations.
Is this correct? Is it simply a case of removing any float declarations and
any code that uses floats to release this memory?
>
Reply by Ananda Regmi●January 8, 20102010-01-08
> Hi Graham,
>
> Your only choice then is the LPC2104-06 parts with more memory and
> "almost" the same pin out. Watch the SPI however!
>
> regards,
> Charles And the JTAG also. LPC2104-6 have two JTAGS (primary and secondary) and
if
you use primary JTAG half of the IO pins are not available in DEBUG mode.
So, if you like to use a debugger and would also like to have access to all
of your IO pins, make sure you use the secondary JTAG.
-Ananda
Reply by "Charles R. Grenz"●January 7, 20102010-01-07
Graham Jones wrote: > Thanks to the many responders, you have been a great
help. Here are my findings and a couple of questions.
>
> Code Sizes with Optimizations Results (CrossWorks)
> --------------
> ARM DEBUG + OPT LEVEL 1 34,940
> ARM DEBUG + OPT LEVEL 2 34,716
> ARM DEBUG + OPT LEVEL 3 34,440
> ARM DEBUG + OPT FOR SIZE 34,440
> ....optimizations won't solve my problem.
>
> Code Sizes for Various Builds Results (CrossWorks)
> --------------
> ARM DEBUG 36,116
> ARM RELEASE 27,708
> THUMB FLASH DEBUG 27,872
> THUMB FLASH RELEASE 21,416
> .....thumb *will* solve my problem
>
>
> Finally, I think that Michael Freeman's advice is critical, I am at
prototype stage with my project and I am already hitting the limits so I need to
factor in many future customer-driven requirements which means I need a more
capable CPU. And now for another prototype.....
>
> Thanks again for all your help!
>
> Best Regards,
> Graham Hi Graham,
Your only choice then is the LPC2104-06 parts with more memory and
"almost" the same pin out. Watch the SPI however!
regards,
Charles
Reply by Graham Jones●January 7, 20102010-01-07
Thanks to the many responders, you have been a great help. Here are my findings
and a couple of questions.
Code Sizes with Optimizations Results (CrossWorks)
--------------
ARM DEBUG + OPT LEVEL 1 34,940
ARM DEBUG + OPT LEVEL 2 34,716
ARM DEBUG + OPT LEVEL 3 34,440
ARM DEBUG + OPT FOR SIZE 34,440
....optimizations won't solve my problem.
Code Sizes for Various Builds Results (CrossWorks)
--------------
ARM DEBUG 36,116
ARM RELEASE 27,708
THUMB FLASH DEBUG 27,872
THUMB FLASH RELEASE 21,416
.....thumb *will* solve my problem
Memory Map
----------
I dumped the memory map into Excel and sorted by code size. I have pasted it
inline below. I think it tells me to work on "SetupNewGame" and "PlayGame".
The former I can definitely optimize.
The calls FPCONV, FPDIV, FPMUL, FPADD, I assume are floating point operations.
Is this correct? Is it simply a case of removing any float declarations and any
code that uses floats to release this memory?
Reply by Paul Curtis●January 7, 20102010-01-07
>> Stdio.h and string.h will use a lot lot of flash up
just by including
>> them, around 6 to 10K.
>
> Only in really really bad implementations. Standard header files rarely
> bring in extra code. And nothing I can think of in string.h is very
> large. Check your map files though.
This is only true if you do no support locales and don't use locale-aware
functions with a locale-capable library. A full C librarry with locale
support is quite heavy. This is something I'm working on now as we've
had
a number of requests to support wide characters.
> The stdio functions do tend to bring in large amounts
of code since they
> are meant to deal with file systems. The printf families are
> particularly notorious.
The overhead is the formatter--typically a language processor has to
include support for all conversion specifiers, whether you use them or
not, which means dragging in floating point even if you never use it. So
there are implementations where you choose a library containing a subset
formatter, or provide your own, or just don't use it.
> Check for duplicate functionality that can be
common-ed and data that
> can be calculated rather than stored and convert frequently used macros
> to functions (frequently may mean >=2). Consider removing floating point
> if you use it in only a small area.
>
> Measure (map files again) after each change.
After building with CrossWorks, the project explorer statistics column
will show module figures for code and data sizes, and overall linked code
sizes, in red if sizes increase, green if they decrease, and no
highlighting indicates no change. Map files? So yesterday...
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
Reply by FreeRTOS Info●January 7, 20102010-01-07
Graham Jones wrote: > Hello Group,
>
> I have been developing a program on ARM7 LPC2103 for a year. The project has
grown steadily. I am driving UART1, LCD, and some GPIO ports. Recently I
started to add code to save into flash and discovered that my program was
already 31KB and almost at the limit of the CPU's flash.
>
> I am using Keil but in the last few days I downloaded CrossWorks eval and
rebuilt the project but it ended up creating a 36KB code size! What I discovered
so far is that if I remove floating point support from sprintf (which I use but
I can code around), I can save several KB the project then uses 29.5KB. Soon I
need to add SD/MMC card functionality so I think I need to free up quite a bit
of space.
>
> My question is this: What would you recommend as a standard check list of
things I should go through to save memory/flash code space?
>
> Other than standard C code of my program I use only the following external
calls:
> - sprintf
> - strcpy
> - strlen
>
Generally Keil will produce good code and has its own small libraries
from what I remember (I use a lot of compilers, its a bit of a blur).
When using a GCC based tool make sure you have the compiler options that
remove unused code switched on. Vanilla GCC will not have them on by
default, although CrossWorks does.
If you are not using floating point support then consider also not using
any of the standard libraries. You can implement simple functions like
strlen() yourself, or use something light weight off the shelf. If you
search the FreeRTOS download your will find multiple copies of
printf-stdarg.c which is an open source (not written by me, see the
comments at the top of the file for credits) file that contains a few
library functions such as sprintf(). I have found a very basic demo
program that uses sprintf() to compile to >25K using Newlib and <6K when
using printf-stdarg.c. It is however very basic and might not be good
enough for your needs. The version in the FreeRTOS download contains a
few bug fixes. Also make sure the LGPL license is ok for your application.
> I am using Keil but in the last few days I downloaded
CrossWorks eval
> and rebuilt the project but it ended up creating a 36KB code size! What
CrossWorks is based on gcc which from my experience is not good for code
reduction. A alternative with respect to code size reduction wood be IAR
(KickStart version is limited to 32K, which is you limit anyway).
You did not tell the basic information, so :
Do you optimize for size already ?
Do you use thumb code ?
Do you tell the linker to remove unneeded function ?
Do not use inline functions.
Check if your strings are only in flash and not copied to RAM ( i.e. use :
const char const * strings[]). > Other than standard C code of my program I use only
the following
> external calls: - sprintf - strcpy - strlen
strcpy and strlen aren't bad, you can't do better by replacing with
hand-written code.
But sprintf is evil. Check what you need from it and maybe you can replace
sprintf by a custom function.
--- In l..., "Graham Jones" wrote: >
> Hello Group,
>
> I have been developing a program on ARM7 LPC2103 for a year. The project has
grown steadily. I am driving UART1, LCD, and some GPIO ports. Recently I
started to add code to save into flash and discovered that my program was
already 31KB and almost at the limit of the CPU's flash.
>
> I am using Keil but in the last few days I downloaded CrossWorks eval and
rebuilt the project but it ended up creating a 36KB code size! What I discovered
so far is that if I remove floating point support from sprintf (which I use but
I can code around), I can save several KB the project then uses 29.5KB. Soon I
need to add SD/MMC card functionality so I think I need to free up quite a bit
of space.
>
> My question is this: What would you recommend as a standard check list of
things I should go through to save memory/flash code space?
>
> Other than standard C code of my program I use only the following external
calls:
> - sprintf
> - strcpy
> - strlen
>
> Best Regards,
> Graham
>
I was using the LPC2103 as well and had to upgrade to a bigger processor.
This is almost always the case for me. A lot of times it's the ASCII
strings cuz I tend to have lots of menus. In that case, I store that stuff in
an external flash or eeprom chip.
I also do what Michael Freeman mentioned and look at the assembly output to
see
where the BIG stuff is. sprintf() might be one. Optimization of
course, check that... Does the Kiel compiler allow you to select
the library configuration and prinf formatter (like IAR) ?? Big, Tiny, Full
etc...
Also, have you tried compiling in THUMB mode ?? That can help quite a bit.
