On Tue, Oct 25, 2016 at 12:01 AM, Mike Looijmans <mike.looijm...@topic.nl> wrote: > Usually the term "real time" is applied to too many things. For example, > your desktop PC experiences latencies of over 1 ms for typical interrupts, > but it still functions fine when running various audio and video > applications that have real-time requirements far below that. The trick is > to go from "you must read a sample from the ADC 44100 times per second" to > "the DMA extracts samples at 44100 Hz and you must copy the data from the > DMA buffer at least once per second".
So one way is to set up some buffers in DDR RAM for the PL to write to and then, based on perhaps an FPGA interrupt, Linux would go and read those buffers? In this case, the buffers in RAM would have to be marked by Linux as uncached, is that correct? Would this be accomplished via the device tree? Or would there be a DMA controller in the PL and Linux goes through that instead of directly to RAM? Thanks so much for this, Mike. I'm learning a lot. > On the Zynq, I move the hard real time tasks to the FPGA where they belong. > Even in AMP mode, the CPU isn't actually a real-time system, because it will > still have to compete with other periferals (and the other CPU) for memory > bandwidth and other resources. It's still possible to have something on the > system cause the 'realtime' CPU to stall for an inderterminate time. > > Linux running on the ARM cores, without any RT patch, is perfectly capable > of handling say 10,000 interrupts per second reliably. So even if you decide > to run a motor control loop on the CPU, that'll work just fine. > > > > Kind regards, > > Mike Looijmans > System Expert > > TOPIC Products > Materiaalweg 4, NL-5681 RJ Best > Postbus 440, NL-5680 AK Best > Telefoon: +31 (0) 499 33 69 79 > E-mail: mike.looijm...@topicproducts.com > Website: www.topicproducts.com > > > -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
