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
Saving Memory in LPC2103
Started by ●January 6, 2010
Reply by ●January 6, 20102010-01-06
First question, have you turned on the optimizer yet? Second, are you stuck
using the LPC2103?
I have not used the LPC2103. We use LPC21xx and LPC23xx series of chips.
Both have pin compatible memory upgrade paths, upto 512K. That's how I fight
feature creep. I have been burned one to many times not having the option to
upgrade the hardware, those damm costumers always want more stuff later.
If you are stuck, look at the asm listing of your code. Then read code it
in asm. You can always pack code better than the optimizer. Also if you are
using stdio.h and string.h you probably have strings in your code. Those
strings will eat your flash up without you knowing it. Stdio.h and string.h
will use a lot lot of flash up just by including them, around 6 to 10K.
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
Graham Jones
Sent: Wednesday, January 06, 2010 8:32 PM
To: l...
Subject: [lpc2000] Saving Memory in LPC2103
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
using the LPC2103?
I have not used the LPC2103. We use LPC21xx and LPC23xx series of chips.
Both have pin compatible memory upgrade paths, upto 512K. That's how I fight
feature creep. I have been burned one to many times not having the option to
upgrade the hardware, those damm costumers always want more stuff later.
If you are stuck, look at the asm listing of your code. Then read code it
in asm. You can always pack code better than the optimizer. Also if you are
using stdio.h and string.h you probably have strings in your code. Those
strings will eat your flash up without you knowing it. Stdio.h and string.h
will use a lot lot of flash up just by including them, around 6 to 10K.
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
Graham Jones
Sent: Wednesday, January 06, 2010 8:32 PM
To: l...
Subject: [lpc2000] Saving Memory in LPC2103
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
Reply by ●January 6, 20102010-01-06
Opps, recode not "read code"
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
Michael Freeman
Sent: Wednesday, January 06, 2010 9:09 PM
To: l...
Subject: RE: [lpc2000] Saving Memory in LPC2103
First question, have you turned on the optimizer yet? Second, are you
stuck using the LPC2103?
I have not used the LPC2103. We use LPC21xx and LPC23xx series of chips.
Both have pin compatible memory upgrade paths, upto 512K. That's how I fight
feature creep. I have been burned one to many times not having the option to
upgrade the hardware, those damm costumers always want more stuff later.
If you are stuck, look at the asm listing of your code. Then read code it
in asm. You can always pack code better than the optimizer. Also if you are
using stdio.h and string.h you probably have strings in your code. Those
strings will eat your flash up without you knowing it. Stdio.h and string.h
will use a lot lot of flash up just by including them, around 6 to 10K.
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On Behalf
Of Graham Jones
Sent: Wednesday, January 06, 2010 8:32 PM
To: l...
Subject: [lpc2000] Saving Memory in LPC2103
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
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
Michael Freeman
Sent: Wednesday, January 06, 2010 9:09 PM
To: l...
Subject: RE: [lpc2000] Saving Memory in LPC2103
First question, have you turned on the optimizer yet? Second, are you
stuck using the LPC2103?
I have not used the LPC2103. We use LPC21xx and LPC23xx series of chips.
Both have pin compatible memory upgrade paths, upto 512K. That's how I fight
feature creep. I have been burned one to many times not having the option to
upgrade the hardware, those damm costumers always want more stuff later.
If you are stuck, look at the asm listing of your code. Then read code it
in asm. You can always pack code better than the optimizer. Also if you are
using stdio.h and string.h you probably have strings in your code. Those
strings will eat your flash up without you knowing it. Stdio.h and string.h
will use a lot lot of flash up just by including them, around 6 to 10K.
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On Behalf
Of Graham Jones
Sent: Wednesday, January 06, 2010 8:32 PM
To: l...
Subject: [lpc2000] Saving Memory in LPC2103
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
Reply by ●January 6, 20102010-01-06
--- In l..., "Graham Jones" wrote:
>
> 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
>
Before doing anything else study the memory map that Keil generates when linking your program. You can then identify the modules that are consuming the most code space and focus your memory-reduction efforts on them.
--
Chris Burrows
CFB Software
Armaide: LPC2000 Oberon-07 Development System
http://www.armaide.com
>
> 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
>
Before doing anything else study the memory map that Keil generates when linking your program. You can then identify the modules that are consuming the most code space and focus your memory-reduction efforts on them.
--
Chris Burrows
CFB Software
Armaide: LPC2000 Oberon-07 Development System
http://www.armaide.com
Reply by ●January 6, 20102010-01-06
2nd opps, lpc213x not lpc21xx.
Going to bed now
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
Michael Freeman
Sent: Wednesday, January 06, 2010 9:12 PM
To: l...
Subject: RE: [lpc2000] Saving Memory in LPC2103
Opps, recode not "read code"
-----Original Message-----
From: l... [mailto:l...]On Behalf
Of Michael Freeman
Sent: Wednesday, January 06, 2010 9:09 PM
To: l...
Subject: RE: [lpc2000] Saving Memory in LPC2103
First question, have you turned on the optimizer yet? Second, are you
stuck using the LPC2103?
I have not used the LPC2103. We use LPC21xx and LPC23xx series of chips.
Both have pin compatible memory upgrade paths, upto 512K. That's how I fight
feature creep. I have been burned one to many times not having the option to
upgrade the hardware, those damm costumers always want more stuff later.
If you are stuck, look at the asm listing of your code. Then read code
it in asm. You can always pack code better than the optimizer. Also if you
are using stdio.h and string.h you probably have strings in your code. Those
strings will eat your flash up without you knowing it. Stdio.h and string.h
will use a lot lot of flash up just by including them, around 6 to 10K.
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On
Behalf Of Graham Jones
Sent: Wednesday, January 06, 2010 8:32 PM
To: l...
Subject: [lpc2000] Saving Memory in LPC2103
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
Going to bed now
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
Michael Freeman
Sent: Wednesday, January 06, 2010 9:12 PM
To: l...
Subject: RE: [lpc2000] Saving Memory in LPC2103
Opps, recode not "read code"
-----Original Message-----
From: l... [mailto:l...]On Behalf
Of Michael Freeman
Sent: Wednesday, January 06, 2010 9:09 PM
To: l...
Subject: RE: [lpc2000] Saving Memory in LPC2103
First question, have you turned on the optimizer yet? Second, are you
stuck using the LPC2103?
I have not used the LPC2103. We use LPC21xx and LPC23xx series of chips.
Both have pin compatible memory upgrade paths, upto 512K. That's how I fight
feature creep. I have been burned one to many times not having the option to
upgrade the hardware, those damm costumers always want more stuff later.
If you are stuck, look at the asm listing of your code. Then read code
it in asm. You can always pack code better than the optimizer. Also if you
are using stdio.h and string.h you probably have strings in your code. Those
strings will eat your flash up without you knowing it. Stdio.h and string.h
will use a lot lot of flash up just by including them, around 6 to 10K.
Michael Freeman
-----Original Message-----
From: l... [mailto:l...]On
Behalf Of Graham Jones
Sent: Wednesday, January 06, 2010 8:32 PM
To: l...
Subject: [lpc2000] Saving Memory in LPC2103
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
Reply by ●January 6, 20102010-01-06
How big is it in Thumb mode?
_____
From: l... [mailto:l...] On Behalf Of
Graham Jones
Sent: Wednesday, January 06, 2010 6:32 PM
To: l...
Subject: [lpc2000] Saving Memory in LPC2103
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
_____
From: l... [mailto:l...] On Behalf Of
Graham Jones
Sent: Wednesday, January 06, 2010 6:32 PM
To: l...
Subject: [lpc2000] Saving Memory in LPC2103
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
Reply by ●January 6, 20102010-01-06
On 06/01/2010 10:08 PM, Michael Freeman wrote:
> Also if
> you are using stdio.h and string.h you probably have strings in your
> code. Those strings will eat your flash up without you knowing it.
Definitely worth checking. If that is the case even simple compression
can make a difference.
> 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.
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.
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.
Robert
--
http://www.aeolusdevelopment.com/
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live....
we currently have stock."
> Also if
> you are using stdio.h and string.h you probably have strings in your
> code. Those strings will eat your flash up without you knowing it.
Definitely worth checking. If that is the case even simple compression
can make a difference.
> 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.
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.
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.
Robert
--
http://www.aeolusdevelopment.com/
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live....
we currently have stock."
Reply by ●January 6, 20102010-01-06
--- 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.
boB
>
> 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.
boB
Reply by ●January 7, 20102010-01-07
Graham
> 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.
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
> 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.
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Reply by ●January 7, 20102010-01-07
42Bastian
> 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
Sorry for my "just-woke-up-early-morning-English" :-)
1) My experience with gcc not CrossWorks !
2) _An_ not _A_ alternative
3) _would_ not _wood_ :-)
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
> 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
Sorry for my "just-woke-up-early-morning-English" :-)
1) My experience with gcc not CrossWorks !
2) _An_ not _A_ alternative
3) _would_ not _wood_ :-)
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
