Lpc2000

Keith,

You (and others) can relax - I'm back home now from a recent 
business trip and already I can feel all the extra free time 
draining away, so I won't be contributing as much for a while. Much 
to some people's relief I'm sure.

As for your own problem, without more detail, all I can suggest are 
some general pointers (which you're probably aware of anyway):

1. You've already done the 1st one, which is to ask here. I assume 
you've also read the manuals and errata thoroughly?

2. You mention you're overclocking the ADC: is this some figure in 
the manual you're exceeding? If so, I'd strongly recommend you 
don't. The figure is there for a reason. Yes I know that in normal 
conditions you'll probably get away with it (Philips are quite 
conservative in their specs), but as you don't know what the effects 
might be or when they might occur, it's asking for trouble.

3. You're driving the part quite hard at the rates you're talking 
about, particularly if each ADC conversion is handled in an 
interrupt. You may just be running out of MIPS, which can cause all 
sorts of unpredictable behavior. A quick and dirty test to do is 
turn on the optimizer (you mention it's off): this can have a big 
effect on throughput. However, you're almost worse off if the 
problem goes away when you try this, as you actually haven't proved 
anything (unless the whole thing is just a quick-and-dirty project 
to get some once-off results, in which case it doesn't matter).

4. After that, the only thing I can suggest is the normal methodical 
approach: understand how your system is behaving (e.g. by putting in 
extra counters, flags etc. to confirm things are happening when you 
believe them to be, in the right order, that things aren't being 
dropped or missed etc.). Once you've done that, work back from the 
symptoms (which sounds difficult in your case), or alternatively 
work forward by hypothesizing what might be going wrong, design a 
test to check and verify. But then I'm sure you know all this 
already.

As a final observation, high interrupt rates have a habit of 
flushing out otherwise latent bugs in software: sounds like you have 
a good test system for you software!

Some of this is stating the obvious, but hopefully there's something 
of use for you (and others) there.

Brendan

--- In lpc2000@yahoogroups.com, "pitstock_kiwi" <keith@...> wrote:
>
> Greetings
> 
> While Brendan and Jaya have been furiously writing emails I have 
been 
> working on my LPC2148 ADC code. Its taken me a while but I now 
have 
> it clocking out the ADC at a rate of 520 K samples per second. I 
am 
> over clocking the ADC a little at 5 Mhz but my noise is well 
within 
> my required spec. I didn't think it was possible as I always hit 
> about 320 K or so at best. My 512 pixel camera is now doing over 
500 
> frame captures per second :)
> 
> The caputured frames are dispatch to the PC via the USB HID 
example. 
> I have not got the HID example to run very stable yet (has 
anyone ?). 
> I can send packets (64 byters) to the PC no problem at a fair rate 
> (5ms). Just when I send packets from the PC to the 2148 I 
> intermittently get a permanent code slow down and the USB stops 
> communication (but stays connected). If anyone knows the solution 
to 
> this I would be happy to hear it.
> 
> My Setup is:
> Keil 3.31 using the ADS realview that came with it. ARM mode with 
no 
> optimising. Keil MCB2140 dev board with a ULINK.
> 
> Cheers
> Keith
>