Lpc2000

At 09:58 AM 1/2/04 -0800, you wrote:
>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)

CLOCK_SPEED is a target speed for the timer.  The startup for the timer 
routines sets the prescaler to get the timer as close to CLOCK_SPEED as it 
can without going below it.  It gets the oscillator input frequency from 
SetNativeSpeed (It shouldn't be necessary to recompile the library if you 
change the oscillator frequency, just change the call to 
SetNativeSpeed).  The reason for choosing the value I did for CLOCK_SPEED 
was to provide resolution in the counter better than needed for timing, 
delay overflow of the counter as long as possible and to make the number of 
counter increments per microsecond an integral number to avoid and errors 
due to finite precision.  The actual timer frequency gets recorded in 
timing_scale_factor and the ratio timing_scale_factor/CLOCK_SPEED is used 
to correct any mismatch due to the actual frequency not matching the 
requested nominal frequency.

Now to work through a few examples with various settings

First a 10MHz oscillator,   CLOCK_SPEED set to 10000000, COUNTS_PER_US to 
10, CPU pll'd to 60MHz and VPBrate to div by 1.  We get a timer frequency 
of 10000000 (prescale divide by 6).

uS counts Should Be Actual uS Min wait
1 10 10 1 0.9
2 20 20 2 1.9
3 30 30 3 2.9
4 40 40 4 3.9
5 50 50 5 4.9
6 60 60 6 5.9
7 70 70 7 6.9
8 80 80 8 7.9
9 90 90 9 8.9
10 100 100 10 9.9
1000 10000 10000 1000 999.9


Second a 14.745MHz oscillator,   CLOCK_SPEED set to 14745000, COUNTS_PER_US 
to 15, CPU pll'd to 58.98MHz and VPBrate to div by 2.  We get a timer 
frequency of 14745000 (prescale divide by 2).

uS      counts  Should Be       Actual uS       Min wait
1       15      14.745          1.01729 0.94947
2       30      29.49           2.03458 1.96676
3       45      44.235          3.05188 2.98406
4       60      58.98           4.06917 4.00135
5       75      73.725          5.08646 5.01865
6       90      88.47           6.10376 6.03594
7       105     103.215 7.12105 7.05323
8       120     117.96          8.13835 8.07053
9       135     132.705 9.15564 9.08782
10      150     147.45          10.1729 10.1051
1000    15000   14745           1017.29 1017.22


Third a 14.745MHz oscillator,   CLOCK_SPEED set to 10000000, COUNTS_PER_US 
to 10, CPU pll'd to 58.98MHz and VPBrate to div by 2.  We get a timer 
frequency of 14745000 (prescale divide by 2).

uS      counts  Should Be       Actual uS       Min wait
1       14      14.745          0.94947 0.88165
2       29      29.49           1.96676 1.89894
3       44      44.235          2.98406 2.91624
4       58      58.98           3.93353 3.86571
5       73      73.725          4.95083 4.88301
6       88      88.47           5.96812 5.90030
7       103     103.215 6.98541 6.91759
8       117     117.96          7.93489 7.86707
9       132     132.705 8.95218 8.88436
10      147     147.45          9.96948 9.90166
1000    14745   14745           1000            999.932

Note that because the nominal timer frequency is chosen so that there are 
an integral number of counts per uS the error that occurs because the 
actual frequency does not allow that get corrected by the 
timing_scale_factor rather than by COUNTS_PER_US.  Both numbers can only be 
accurate to +/-1 but since timing_scale factor is so much larger to begin 
with the error it introduces is much less (6 orders of magnitude).  Of 
course this still neglects the constant call overhead.


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

Good point.  There is an init that takes place on the first call.  I'll 
move that out.

>
>BTW, so far this will be entirely adequate for my needs.  I was just 
>testing the lower boundary to see how it would perform...

Great.  I still think I'll make it a little bit better though.

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