Lpc2000

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