From your description, the issue maybe linked to your
delay routine and compiler optimization.
Implementing delays using loop structures in C such as your example:
Code:
void delay()
{
unsigned int i,j;
for(i=0;i<50;i++)
for(j=0;j<12750;j++);
}
Are precarious at best. Delay routines such as these may compile fine in one version of the compiler and then maybe suddenly "optimized," in whole or in part, out of exist in the next revision.
If you examine your delay routine, you will notice the affected variables are only those with local scope to that routine.
In essence, as far as the compiler is concerned, the delay routine accomplishes nothing and therefore maybe subject to modification/deletion during the optimization phase, which could account for the difference in the sizes of the compiled code that you have indicated.
I would suggest examining the compiled codes in a disassembly windows to determine what exactly has been modified or deleted to reduce the size from 4kB to 2kB.
If the issue is due to optimization, you maybe able to remedy the situation by the use of the keyword
volatile during the declaration of both variables
i and
j within the delay routine or declaring another volatile variable which is incremented or decremented within each
for loop.
However, it should be noted the keyword
volatile and its impact during compilation process is heavily compiler dependent, which once again puts you at the mercy of the compiler version.
A more optimal solution would be to utilize the devices timers or if a software coded delay is absolutely necessary, code such delays in Assembly language.
The vast majority of
delay routines offer by embedded compiler libraries are in fact written in Assembly language for this reason as well as being deterministic concerning the actual delay time interval, which cannot be said for those
delay routines written in C or another high level language (HLL).
BigDog