Lpc2000

Karl,

When I said "wow!", I meant "neat": it's a good solution. As I'm 
sure you'll agree, having to come up with somethinkg like this, or 
milti-level interrupts, so something equally strange is a real pain: 
all the for lack of a single latch signal to the DAC.

I've pointed this out to Philips in the past: hopefully, they'll 
recognise from this that others have the same issue.

None of the work-arounds presented are ideal: a h/w fix is much more 
preferable.

Brendan

--- In lpc2000@yahoogroups.com, "Karl Olsen" <kro@p...> wrote:
>
> ---- Original Message ----
> From: "brendanmurphy37" <brendan.murphy@i...>
> To: <lpc2000@yahoogroups.com>
> Sent: Friday, January 20, 2006 4:38 PM
> Subject: [lpc2000] Re: D/A noise
> 
> > Wow! that's getting really esoteric!
> >
> > Magnus: Karl is right about the jitter. Even without the delay
> > introduced by the timer register being on the peripheral bus, you
> > have to take into acount the timer could tick either imediately 
after
> > you load it or any time from then until you load it again. Even 
if
> > the number of instructions and clocks in this is always the 
same, the
> > tick could happen anywhere in the sequence.
> 
> You should have no pclk or timer prescaler so that the timer ticks 
at the
> cclk rate.  So during a single load from T0TC, it actually 
increments eight
> times.  Exactly in which of the eight clocks the T0TC value is 
latched
> doesn't really matter jitterwise, as long as it is the same every 
time.
> 
> I just tried this program on my LPC2103:
> 
> /* Vector area relocated to RAM */
> /* r8_fiq preloaded with T0 = 0xE0004000 */
> /* r9_fiq preloaded with address of ram_fiqhandler */
> 
> /* 0x001C: */
> 
> /* Timer 0 has just generated an interrupt and been reset.  T0TC 
is now
>  * a small positive number that tells how many clocks it took to 
enter the
>  * FIQ handler. */
> ldr  r10, [r8, #+8]   /* r10 = initial T0TC */
> 
> /* If it is not unreasonably large (indicating an unexpected big 
latency,
>  * such as if somebody has had FIQs disabled), jump into 
ram_fiqhandler,
>  * skipping as many nops as we have already spent clocks. */
> cmp  r10, #32
> addls pc, r9, r10, lsl #2
> 
> /* It was unreasonably large, jitter not completely eliminated.
>  * Just skip all the nops. */
> add  pc, r9, #4*32
> 
> 
> ram_fiqhandler:    /* located in RAM */
> nop
> nop
> ... total 32 nops
> nop
> ldr  r11, [r8, #+8]   /* r11 = final T0TC */
> ...
> 
> At this time, r10 is the initial T0TC value, and r11 is the T0TC 
value after
> jitter elimination.
> 
> The program showed that the initial T0TC value varied between 9 
and 16, and
> the final T0TC was always 44.  So the normal FIQ jitter of 7 
clocks (which
> could be larger if the foreground contained things like big 
ldm/stm's) was
> reduced to a jitter of 0.
> 
> I think this method is simpler and wastes fewer clocks than multi-
stage
> interrupt handlers.  But I still think that Philips should have 
added some
> hardware synchronisation to the DAC.
> 
> Karl Olsen
>