It looks like the Linux speed is fine for this application.
There is a huge advantage to running the Linux that comes installed in the uZed. No Linux to recompile!
If we have realtime problems (which I don't think we will) the second ARM core is available. We could ask Linux to run the signal processing app on it, or even run the app bare metal on the second core. So we have a bailout if we ever need it.
--
John Larkin Highland Technology, Inc
jlarkin at highlandtechnology dot com
I can confirm that it is quite possible to reconfigure the FPGA from a C program after the OS is running.
You removed the FPGA config step from the bootloader, and now it doesn't work?
My first guess would be that the (so-called) voltage translation buffers between the ARM and the FPGA have not been enabled. There's a magic register somewhere that you need to write to before anything will work.
Get Rob to look through the (massive) TRM one more time...
My guys are building the whole boot image using the Xilinx tools, which combine the OS and the FPGA and boot-load it all, and that works. My customer would like to be able to upload separate files that are the application program and the FPGA image, so I'd like to figure out how to do that.
Rob has been busy on a couple of other projects, and I'm busy on the signal processing architecture and the host board hardware design, so Paul (my embedded programmer) and Blaine (our FPGA consultant) have been doing the serious work on this. The secondary FPGA load thing hasn't been first priority... talking to an FPGA register was, and now the signal processing is the next step.
Someone should write a book, Zed For Dummies. I'd buy one.
If anybody knows the details of reloading the FPGA live, I'd appreciate any hints or references that I could pass on to the boys.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
While the financial industry was once a hotbed for interest in realtime, that seems to have cooled somewhat. The traders are more interested in throughput and are willing to allow Linux to miss some latency deadlines in the interests of throughput, Hart said. The embedded use cases for realtime seem to be where the "action" is today, Gleixner and others said, but there has been little effort to fund realtime development coming from that community.
Beagleboards use TI AM335x which has two PRU units: embedded simple CPUs that run at 200MHz and execute programs from a memory area that can be accessed (for data and/or code) from the main ARM CPU.
Some I/O pins are directly accessible from the PRU and others go through the general IO. In theory the former can be flipped every 5 ns---in practice Charlie Steinhauer discovered pipeline effects that limit it somehow, but still, you can get a good fraction of 100MHz.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.