Dear Friends,
I am using an ARM7 LPC2129 controller with 10~Mhz external oscillator. My controller is running at 60Mhz and PCLK at 30Mhz.
I have a quick question for you. I want to write a delay function this way:
void Delay (unsigned char DelayInMilliSec) { unsigned long Timing,Loop;
for(Loop=0;Loop<DelayInMilliSec;Loop++)
for(Timing=0;Timing<xxxxx;Timign++); //I want one milli Second delay here
}
What value should I keep in place of xxxxx to generate a one milli second delay. I donot want to use the timer functionality. It will be ok using the NOP instruction, but please guide me what should be done to generate the one milli second delay in place of second for loop..
Thank you dudes in advance for the reply.
What you want and what you should may not always be the same thing.
The answer is simple. You should not do a counted software delay.
Configure a timer, read out the timer value and poll it until x ms have passed. This is trivial, and will not be affected by changes of compiler optimizations, changes of flash caching etc.
Here's a classic example of what not to do:
/* Reset Reduced MII Logic. */ MAC_SUPP = SUPP_RES_RMII; for (tout = 100; tout; tout--); MAC_SUPP = 0;
It fails when full optimization (-O3) is selected.
And where does it come from? LPC32_EMAC.C And who supplies it? KEIL
Whoops.
Yes IB Shy! I also say it, and I suspect there is more...
Here is more (MCI_24xx.c, version 4.11):
/* Power up, switch on VCC for the Flash Card. */ MCI_POWER = 0x02; for (i = 0; i < 50000; i++);
Come on, Keil !
Hi ! In many Keil example I see such HLL loops (LCD read/writes). I really got aware of this probem with -O3 optimization ( as it may unroll loops).
If you REALLY don't want to use timer, use the method supplied above to write assembly code and then use an ouptut to measure code duration with a scope.
Regards, Selso.
I wonder if it is really Keil code, or code from NXP.
NXP have released some really shitty code - at least for their ARM chips. The code looks like typical student code.
"I wonder if it is really Keil code, or code from NXP."
In the case of the file LPC32_EMAC.C, I think it does come from Keil - Although some parts may have been derived from NXP code.
The NXP code for the LPC3250 definitely falls into the really shitty category!
Yes, there is certainly Keil code that does it - I think most of their "Blinky" examples do!
While it can be OK for quick-&-dirty stuff like "Blinky", I think Keil really should clearly comment comment the pitfalls - otherwise they are just setting a bad example...