> > >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.
I know that the 'C40s support DMA, but I'm blowed if I can figure out how to
implement it with this A/D board and the backplane. To be honest I don't know
that much how DMA works, so I'm on the steep bit of the learning curve.
The reason I balked at the interrupt time is that it was stated to be as high
as 15us - a large percentage of the 100us period irrespective of DMA. It has
been highlighted to me that this 15us is an absolute worst case!
> 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.
In my control application either ASAP or exactly one period is fine, although
I don't know about the mathematical control implications therein. It would
seem to me that FIFOs or latches are the way to go.
Alternatively I have thought about mapping part of the memory space to the
outputs of a latch that contains the data from the A/Ds and the digital
inputs. This would be the ultimate since it would run at memory bus speed,
you never have to move the data, just use them, and you couldn't write to
these variables. The mapping could be hardwired into the circuit board, or
via a FPGA. Similarly the variables written to the D/A and digital output
buffers could also be mapped to the memory space.
> 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).
If you don't use the ISR to do the control algorithm, where do you do all the
work? In the main programme? If so, how do you synchronise the control
algorithm with the clocking rate? Set a bit in the ISR and check for it in a
while loop? Hey, what a great idea!
--
Andrew Tuckey
Postdoctoral Research Scientist
Eindhoven University of Technology
EE Dept., Group EMV, Room EL 1.13
PO Box 513 Phone: +31 - 40 2 47 3895
5600 MB EINDHOVEN Fax: +31 - 40 2 43 4364
The Netherlands 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/
