-----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/> .