microZed adventures

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 
 Click to see the full signature
Reply to
John Larkin
Loading thread data ...

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...

Allan

Reply to
Allan Herriman

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    
 Click to see the full signature
Reply to
John Larkin

formatting link
The future of realtime Linux November 6, 2013

Lots of info. This may be the important piece:

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.

--
These are my opinions.  I hate spam.
Reply to
Hal Murray

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.

Reply to
Przemek Klosowski

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.