<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Generating delay for LPC1317-64P</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/29931/generating-delay-for-lpc1317-64p</link><description> 
I want to generate delay in generalized manner i.e 
void delay(uint8_t delay_ms). The delay passed in ms. 

 
. So I am using LPC1317-64P, 72MhZ clock. 

 
So to generate delay I have used function, SYSTEM_FREQ =
72000KHZ 

 
void delay(uint8_t delay_ms</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Generating delay for LPC1317-64P</title><link>https://community.arm.com/thread/92948?ContentTypeID=1</link><pubDate>Thu, 24 Jan 2013 01:53:13 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:abc5b99a-fc28-46c9-b9b8-4d86c41d0e07</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
No. Delays in the ms range using a for loop really is not perfect.
It is lousy. Busy-loops can be good for minimal ns or us delays where
the requirement isn&amp;#39;t an exact delay but a guranteed minimum delay.
But that doesn&amp;#39;t mean they are trivial to implement, since the
compiler can throw them away if incorrectly written - and their speed
must be verified.&lt;/p&gt;

&lt;p&gt;
But if you want a 500ms delay, you normally want 500ms independent
of what other things the processor does. So 0% or 50% interrupt load
should only give a bit of jitter in the timing - not a factor two
difference pusing 500ms -&amp;gt; 1000ms.&lt;/p&gt;

&lt;p&gt;
And you do not want an implementation where a change of code
optimization settings, or a change of compiler version, suddenly
makes a huge difference to the delay.&lt;/p&gt;

&lt;p&gt;
And you do not want an implementation where the delay could
actually become almost zero, because all of the loop gets thrown away
for having zero side effects. Better compilers specifically knows
about their &amp;quot;nop&amp;quot; intrinsics and makes sure they aren&amp;#39;t optimized
away - but there are seldom any compiler documentation that
explicitly says so.&lt;/p&gt;

&lt;p&gt;
Why do we so seldom see people who have used timers when
implementing their delay loops post their troubles on this forum?
Might it be because they so seldom have problems? That their delays
actually do what was intended, without interferences from lots of
unknowns inside the compiler or other things the processor may be
busy doing?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Generating delay for LPC1317-64P</title><link>https://community.arm.com/thread/61585?ContentTypeID=1</link><pubDate>Thu, 24 Jan 2013 01:00:32 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:33103a4e-e963-45de-a1f5-6b1079938dda</guid><dc:creator>jj mullah</dc:creator><description>&lt;p&gt;&lt;p&gt;
you have three lines for the nop. so you need to change your math
to&lt;/p&gt;

&lt;p&gt;
cnt = (delay_ms*SYSTEM_FREQ)/3&lt;/p&gt;

&lt;p&gt;
it is perfect&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>