Lpc2000

I used 15 for COUNTS_PER_US.  Are you implying that setting leaving
CLOCK_SPEED at 10000000 and COUNTS_PER_US at 10 would have no
difference?  (I haven't followed this logic line through the code to see
if it holds)
 
One more thing:  I found that the first call to WaitUs took much longer
than expected.  I got around it by making an initial call at the end of
the setup function.  (Forgot to mention that.)
 
BTW, so far this will be entirely adequate for my needs.  I was just
testing the lower boundary to see how it would perform...

-----Original Message-----
From: Robert Adsett [mailto:subscriptions@...] 
Sent: Thursday, January 01, 2004 9:03 PM
To: lpc2100@yahoogroups.com
Subject: RE: [lpc2100] Delay routines


At 04:29 PM 1/1/04 -0800, you wrote:
>Robert,
>
>I ran some side-by-side comparisons on the first vs. the second
versions 
>of delay that you posted.
>Because I know there is call overhead I just put the delay routines in
a 
>loop that sets a pin high, delays, sets pin low, etc. and looked at 
>differences from delay to delay on a logic analyzer, i.e.:
>for (i=2;i<=10;++i)
>{
>     -drive output pin high
>     WaitUs(i);
>     -drive output pin low
>}
>-drive trigger high
>
>The results are interesting (at least to me).  First, there is a
potential 
>bug in both versions:
>Using my CLOCK_SPEED of 14,745,000hz , processor speed of 58,980,000
and a 
>VPB divider of 2 so VPBRate() is 29,490,000, a call to WaitUs(1) takes 
>many minutes to execute.  It hangs in
>
>while( (REG(TIMER0_EMR) & 0x8) == 0).
>
>WaitUs for values > 1 succeeds.  I assume that with a value of 1 the
timer 
>has to go "around the horn" to get back to the target value, hence the
delay.

Unfortunately, yes.    If the delay gets small enough there will be a 
problem.  This should be detectable by calibrating the timer at startup 
(thus the comment about refinement at the top of the file).  Hmm, I also

need more robust documentation.


>However, if I use your original CLOCK_SPEED of 10,000,000 it works OK.
I 
>haven't tracked down in the code why this is happening but I wonder
that 
>with such a short delay the counter is already past the target value 
>before the match gets set?

Hmm,
Set CLOCK_SPEED to 14745000
then you presumably set COUNTS_PER_US to 14? (or 15?)

As a matter of curiosity, why?

I can see where the truncation involved might make the delay fail 
earlier.  I'd have to work through the math to see exactly what the
effect 
would be and it's getting late tonight ;)  I'll take a look tomorrow.

>
>Delays that the logic analyzer (el-cheapo ant16) reports are
interesting:
>i(uS, requested)    Delay (uS, measured)   Difference from previous
>----------------    ----------------       ------------------------
>2                   12
>3                   12.8                   0.8
>4                   13.7                   0.9
>5                   14.9                   1.2
>6                   15.9                   1.0
>7                   16.9                   1.0
>8                   18                     1.1
>9                   18.8                   0.8
>10                  19.8                   1.0
>(These are pretty reproducible from run to run)
>
>So there seems to be a constant overhead factor of 10us in the call.
>
>Question 1:  Does this overhead seem excessive to you for the processor

>running at 60Mhz?

10uS would be 60 instructions at full rate.  A quick operation count
gives 
me 32 operations including a division that will have to be done in SW
(no 
HW div on the ARM).  So it's in the right ball park (documentation
again).

If you need a delay in the uS range you are going to have to get closer
to 
the HW.  On the other hand if you need a delay in the 10's of uS or more

but with uS (or 2) accuracy I think we can make this work.  (For now you

will get +/-10uS or so accurracy, mostly +).

>Question 2:  Does the variation in 'difference from previous' seem
excessive?


Hmm, figure +/ 0.1 from the counter.  Is this with count at 10000000?

Given a vpbrate of 29490000 that will give a rate counter rate of 
14745000.  2us becomes 2*10*14745000/10000000 = 29 counts, 3 uS becomes
44 
counts, and 4 us becomes 58 counts.  Those are respectively (1.9-2.0uS),

(2.92-2.98 uS ), (3.86 - 3.93uS), (4.88-4.95).  You may lose one count
if 
you read from the timer just before it increments.  That gives a
calculated 
set of possible variations of (.92 - 1.08) [for 2us to 3us delay] and, 
(0.86 - 1.01) [for 3uS to 4uS] delay.  If you have CLOCK_SPEED set such 
that you have a non integral number of counts per us truncation errors
will 
add to the variation (finite arithmetic will get you every time).

Let me know what you have CLOCK_SPEED and COUNTS_PER_US set to for this 
measurement, I'd like to work a little further on it.



Nice set of measurements Curt.

>
>Anyone else with thougths/observations/experiences feel free to chime
in...
>
>Curt

Absolutely.  I just moved some of that 'refinement' up my priority list.

Robert



" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III



  _____  

Yahoo! Groups Links


*	To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2100/
  

*	To unsubscribe from this group, send an email to:
lpc2100-unsubscribe@yahoogroups.com
<mailto:lpc2100-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
  

*	Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .