Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

Odd Timer Behaviour

Odd Timer Behaviour

2004-01-20 by Robert Adsett

I've just run into some odd timer behaviour while working on timing 
routines.  I'm going to spend some more time nailing down a good 
demonstration but I thought I would report my preliminary results and see 
what ideas anyone might have.

I'm using one of the match register against T0 to measure a time 
period.  Basically load the match with current count plus whatever count I 
want to wait for and then wait for the timer HW to trigger a match.  When I 
went to measure it I found a discrete jump in the error I was getting at 
around 26 uS.  Delving further I found the time it was taking in counts 
wasn't matching what I was asking for.   For from about 11uS to 25 uS I get 
an error of 1 or maybe 2 counts.  (quite reasonable for the 10MHz frequency 
I'm using), also the error may be positive or negative.  At 26 uS (260 
counts) I suddenly see a wait of at least 268 counts or a consistent 
positive error of 8.  Checking further I find period increments in the 
error at logarithmic time intervals (some sort of bit ripple effect?).  The 
table below shows what I mean.  The first column is the request wait in 
uS.  The second is the excess wait produced in counts.

Request Wait, Excess Counts
20, 0
26, 9
450, 19
6700,28
20100,37
105500,44

The worst case from my view is at the 26uS point where this results in a 3% 
or so error.  After that the error decreases (on a percentage basis).

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

Re: [lpc2100] Odd Timer Behaviour

2004-01-30 by Robert Adsett

At 04:26 PM 1/20/04 -0500, you wrote:
>I've just run into some odd timer behaviour while working on timing
>routines.  I'm going to spend some more time nailing down a good
>demonstration but I thought I would report my preliminary results and see
>what ideas anyone might have.

Found the problem (and have a solution mostly ready). I keep forgetting the 
ARM has no hardware division.  The time was going up as the division had to 
cope with more significant bits.  Since I'm dividing by a constant in this 
case I can replace it with an expansion that takes constant time regardless 
of the value.

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

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.