> > >One of the main delays I want to avoid is getting data from the A/Ds.
> > >currently I'm using a couple of C40s, and I have to slow down the bus speed
> > >(currently using 5 wait states) to get the data from the analogue or digital
> > >I/O boards. With a 10kHz sample rate I don't get much time to move data over
> > >the backplane so I figure that I could do it faster with the chips closer
> > >i.e. on the main board. Again, I'm not sure of the details.
> >
> > Why aren't you using an ADC board which supports DMA? If you did, you
> > wouldn't be worried about the CPU's response time to interrupts.
>
> Might be that DMA isn't particularly helpful if you have a control cycle of a
> single sample. For most applications, it would still make sense to use hardware
> FIFOs or latches triggered from a sample rate clock (to eliminate CPU/software
> induced jitter), but it's possible that the output signal in this case is less
> sensitive to jitter than it is to latency; ie it's better to get the result out
> ASAP, rather than clocking it out exactly one sample period later.
>
> Of course, if there are no such requirements on input->output latency, DMA (or
> possibly hardware FIFOs) is the way to go. Handling a few samples per IRQ saves
> *lots* of CPU power, especially on x86 and other workstation/PC CPUs (deep
> pipelines, prediction, slow RAM/fast cache etc).
In the case of the C40s I think that DMA would improve the performance only if
I could do some more overlapping as shown below. In the 100 us I have to
(1) do the A/D conversion,
(2) move the data from the analogue-digital I/O board into the C40 memory
(five wait states),
(3) do the control algorithm, and
(4) move the resultant data to the analogue-digital I/O board (five wait
states).
One of the bottlenecks is the moving of the data from the I/O board to the
memory of the C40 and back - the 5 wait states. Even if I used DMA I would
still have to use 5 wait states due to the capacitance on the data bus (the
backplane).
However I currently give myself more control algorithm time by overlapping the
A/D conversions and the control algorithm, viz:
|---A/D-Conv---| |---A/D-Conv---| |---A/D-Conv-...
|--Move data and Cont. Algo.--| |--Move data and Cont. Algo.--|
^ ^ ^ ^ ^
| | | | |
100 us int. from 100 us Int. from 100 us
timer I/O board timer I/O board timer
signal signal signal
If I could do some more overlapping with DMA as well I could gain more time,
i.e. the control algorithm would have all 100 us, vis:
|---A/D-Conv---| |---A/D-Conv---| |---A/D-Conv-...
|--DMA-Data-Mv--| |--DMA-Data-Mv--|
|-----Control Algo. Only-----| |--Control Algo.
Only...
^ ^ ^ ^ ^
| | | | |
100 us int. from 100 us int. from 100 us
timer I/O board timer I/O board timer
signal signal signal
^ ^
| |
int. from int. from
DMA DMA
So a vast improvement, and the speed of the backplane doesn't present a
problem given that I can get all the data across before the next A/D
conversion start. Also I will have to make sure that I don't access the
memory data locations after the end of the next A/D conversion (i.e. after
the '.' in " Control Algo. Only" otherwise I will get new data!
What does the actual DMA - the processor or the I/O board? Does there need to
be some form of processor on the I/O board?
--
Andrew Tuckey, Visiting Lecturer
Electrical and Computer Engineering Department
University of Wisconsin - Madison
1415 Engineering Drive
Madison, WI 53706-1691
Email: [EMAIL PROTECTED]
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
