On 4/13/2010 5:34 PM, voltz56 wrote:
> Hmmm, I still thought it would be possible to
generate accurate
> delays down a usec without using interrupts especially in a test
> environment that is running no other code (just the delay routine).
> Iv achieved this on an 8051 I didnt think it would be a problem
> on....
Some notes I made.
http://www.aeolusdevelopment.com/AppNotes/LPC210X/an-timerperformance.pdf
Non-interrupt based, but about 10uS overhead. That could be reduced by
sacrificing dynamic range.
Why do you need uS delays? uS precision is straightforward, single
digit uS delays not so easy.
Robert
--
http://www.aeolusdevelopment.com/
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live....
we currently have stock."
LPC2106 - Problem with accuracy of timer
Started by ●April 13, 2010
Reply by ●April 18, 20102010-04-18
Reply by ●April 22, 20102010-04-22
#define uStimer T0TC
#define TicPeruS 36
Int32U uSstore;
#define ifelapsedwrt(y,x) ((y + (x) - uStimer) & 0x80000000)
#define ifelapseduS(x) (ifelapsedwrt(uSstore,x*TicPeruS))
#define waitus(x) uSstore = uStimer; while (ifelapseduS(x) == 0);
This is what I use for uS timing. It has the advantage that the condition stays true for 0x80000000 ticks, which means no worrying about missing the exact match and going around again.
--- In l..., Robert Adsett wrote:
>
> On 4/13/2010 5:34 PM, voltz56 wrote:
> >
> >
> > Hmmm, I still thought it would be possible to generate accurate
> > delays down a usec without using interrupts especially in a test
> > environment that is running no other code (just the delay routine).
> > Iv achieved this on an 8051 I didnt think it would be a problem
> > on....
>
> Some notes I made.
>
> http://www.aeolusdevelopment.com/AppNotes/LPC210X/an-timerperformance.pdf
>
> Non-interrupt based, but about 10uS overhead. That could be reduced by
> sacrificing dynamic range.
>
> Why do you need uS delays? uS precision is straightforward, single
> digit uS delays not so easy.
>
> Robert
>
> --
> http://www.aeolusdevelopment.com/
>
> From the Divided by a Common Language File (Edited to protect the guilty)
> ME - "I'd like to get Price and delivery for connector Part # XXXXX"
> Dist./Rep - "$X.XX Lead time 37 days"
> ME - "Anything we can do about lead time? 37 days seems a bit high."
> Dist./Rep - "that is the lead time given because our stock is live....
> we currently have stock."
>
#define TicPeruS 36
Int32U uSstore;
#define ifelapsedwrt(y,x) ((y + (x) - uStimer) & 0x80000000)
#define ifelapseduS(x) (ifelapsedwrt(uSstore,x*TicPeruS))
#define waitus(x) uSstore = uStimer; while (ifelapseduS(x) == 0);
This is what I use for uS timing. It has the advantage that the condition stays true for 0x80000000 ticks, which means no worrying about missing the exact match and going around again.
--- In l..., Robert Adsett wrote:
>
> On 4/13/2010 5:34 PM, voltz56 wrote:
> >
> >
> > Hmmm, I still thought it would be possible to generate accurate
> > delays down a usec without using interrupts especially in a test
> > environment that is running no other code (just the delay routine).
> > Iv achieved this on an 8051 I didnt think it would be a problem
> > on....
>
> Some notes I made.
>
> http://www.aeolusdevelopment.com/AppNotes/LPC210X/an-timerperformance.pdf
>
> Non-interrupt based, but about 10uS overhead. That could be reduced by
> sacrificing dynamic range.
>
> Why do you need uS delays? uS precision is straightforward, single
> digit uS delays not so easy.
>
> Robert
>
> --
> http://www.aeolusdevelopment.com/
>
> From the Divided by a Common Language File (Edited to protect the guilty)
> ME - "I'd like to get Price and delivery for connector Part # XXXXX"
> Dist./Rep - "$X.XX Lead time 37 days"
> ME - "Anything we can do about lead time? 37 days seems a bit high."
> Dist./Rep - "that is the lead time given because our stock is live....
> we currently have stock."
>