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
Show quoted textHide quoted text
> optimising. Keil MCB2140 dev board with a ULINK.
>
> Cheers
> Keith
>