--- In "Anouk Ahamitet" <> wrote:
>
> --- In "charliem_1216" <charliem_1216@>
> wrote:
> >
> > Well, you've not given enough details to make any intelligent
> comments.
>
> The A2D in question is http://www.diamondsystems.com/products/dmm32dx
> <http://www.diamondsystems.com/products/dmm32dx%20>
>
> > * What's your input signal like during testing? I guess if you are
> calculating standard deviation, you are holding (or trying) to hold the
> input constant. What readings do you get, and what do you expect?
>
> We're using the A2D in differential mode with constant values on three
> inputs. One input is a 'D' battery with resistors to divide the voltage
> down to 144mv, one is a shorted channel to provide a zero reference, the
> third is a on-board precision 5V source that the vendor's software uses
> for auto-calibration.
>
> > * What sampling frequency?
>
> The A2D runs at 4us / sample. We programmer the A2D to trigger at a 5us
> rate, and it puts values in a FIFO. We discard the first 200 samples in
> the FIFO, and then sum the next 3334 (that equates to 1/60 of a second)
> samples to generate a sample to use. The summing is done in floating
> point.
OK, so you take many of these 'samples to use', and this is where you find the
variance? Do you find any variance within the 3334 data points?
>
> > * How is data taken / transferred from your A/D card? Userland or
> kernel driver?
>
> Userland, I suppose, since the test program is doing direct I/O to the
> A2D card.
Well, I'm confused then. How do you know when to empty the FIFO from
userspace, without an interrupt?
>
> > * What kernel versions for x86 & ARM? glibc versions?
>
> ARM: libc-2.3.6, kernel 2.6.21-ts
> x86: libc-2.3.2, kernel 2.6.19.7-L31-rtai3.6
>
> > * What do you observe about the ARM data? Random noise, HF noise?
>
> We haven't performed that type of analysis.
>
> > * Have you ruled out a bad A/D card on the 7800 system?
>
> It is the same physical card on both systems -- we just swap out the SBC
> and leave all of the other stuff intact. So it always has exactly the
> same inputs and cabling -- except perhaps for differences on the PC-104
> bus.
>
> > My first guesses would be RF interference with your analog stage, or
> timing jitter (your data is not sampled when you think it is), or even
> endian-ness issues.
> >
> > You don't really say what 'code' is running running slower. If you do
> any floating point at all, that can have slight to severe impacts on
> your program speed on ARM, depending on your system. If you are only
> talking of the acquisition time, you really can't discuss it without
> posting the code you are using.
>
> Here's pseudo-code for the way we read a sample:
>
> Tell the A2D to start sampling
> Loop to read 3534 samples
> Sleep 1ms
> Loop while samples in FIFO
> Read sample
> if 200 < SampleNo then
> Sum += Sample '' Sum is a double precision float
> EndIf
> EndLoop
> EndLoop
> UsableSample = Sum / 3334
>
> Thanks for taking the time to look at this.
A well-known problem is the granularity of sleep intervals. Your 1 mS sleep
will be OK on i386 as it uses high resolution timers by default, and you were
using RTAI. But on the TS-7800, I believe you have to rebuild your kernel to
get HRT.
Your 1 mS sleep will actually be 10 or 20 mS, which probably partly accounts
for your code running slower. And that will certainly overflow your 512 (or
1024) sample FIFO. Depending on when you reset the FIFO, you could be reading
older samples (or even samples from the other channel?).
In the spirit of debugging, I would see if you can:
* use a busy loop taking single samples a fast as possible. (Yes, I know it's
not a good practice, but we're debugging here ...)
* Take samples into an array of 16bit integers, rather than using a floating
point accumulator. You can then look at the individual samples for variance or
noise patterns, or for problems in your
* Turn down your sampling rate. Even 333 samples at 20 000 samples/S would be
quite a lot to average. If you are averaging to 1/60, I'm not sure why you
need to sample at 200000/S.
* If do a lot of floating point, even outside of your A/D, try building an EABI
kernel & rootfs. While you are at it, turn on HRT.
I expect you are seeing a difference because you are using userland methods to
acquire data. While they happen to work on x86 due to the higher clock (I
guess?), RTAI, and HRT, the same methods don't do what you expect on ARM. To
fix it, you need to either use a kernel driver that can empty the FIFO on an
interrupt, or dig deeper into your acquisition routine specifics (with the A/D
hardware manual in hand ...). The hardware manual does appear to be quite good
...
Your hardware vendor has a linux driver (rather like VMWare: a kernel mode stub
you compile for your kernel, and a closed source library you can link to).
Have you asked about an ARM version?
Finally (sorry for the rambling ...) your vendor also has a bunch of example C
programs that exercise the A/D without the kernel driver or closed library.
You could run some of those, under both x86 and ARM, to verify that the board
is OK with the TS-7800.
regards, ......... Charlie
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|