it isn't that slow, there is a bit of latency but you can do bursts at full bus speed
read/write from DDR ram via the GP axi slave ports are is about a page of RTL, I believe the standard UIO driver now supports allocating coherent memory buffers and getting the physical address for DMA
or you can "cheat" and tell the kernel you have say 1000MB of memory that leaves the upper 24MB unused and at a known address
Speeds might be similar but you can have much larger buffers
een-panel-i2c-spi-serial
with standard linux graphics
?
the one I use only sticks out about 15mm and it is right under the Ethernet connector so there is already something sticking out
What is the programming langauage ? Are you using shell scripts, or plain ld C ? Either way, inside a wrwpper function/objewct the file is opened by one function, and some data(e.g., first 20 bytes) is read out by the function that opened the file, and then the same file pointer is passed to the second function that completes the rest of the task. The C language allows the file pointer to be relocated to any position in the file, and so this is not an issue. A little tricky, but no major issues. You might try the Google group 'comp.lang.c'.
o have one program open a file, read a little from it, then turn it over to another program that reads the rest of the file, all the way to EOF.
ld C ? Either way, inside a wrapper function/object the file is opened by o ne function, and some data(e.g., first 20 bytes) is read out by the functio n that opened the file, and then the same file pointer is passed to the sec ond function that completes the rest of the task. The C language allows the file pointer to be relocated to any position in the file, and so this is n ot an issue. A little tricky, but no major issues. You might try the Google
I went back and reviewed some of OP's postings:
So, this is really an asynchronous task that modify the behavior of the sta te machine.
rm output simultaneously on all channels. The FIFO can hold 32K samples, so we'd always pre-load it with, say, 28K. gen would, ideally, turn over to t he file demon the responsibility to keep reading the file and topping-off the FIFO as needed, then terminate.
The "file daemon" is really a resident task that never terminate, so it can accept the asynchronous task "gen".
e circuit designer) but I am doing the product definition, customer negotia tion, and the general architecture. There are a zillion possible states: st artup, shutdown, EOF, fifo-dry errors, multi-channel time and phase syncs, errors, visibility issues, potential races and hangups. I tend to think in simple, synchronous state machines, so I want to avoid sockets and stuff th at I can't totally understand (ie, avoid asynchronous state machines). Seem s like Linux isn't perfectly suited to this application, but it's pretty mu ch mandatory. The compute platform is a microZED with the Xilinx 7020 SOC, dual-core ARM and FPGA on one chip. Waveform files will be on a 128 Gbyte S D card, which is a speed bottleneck.
What you don't understand does not mean it's not the right thing to do so.
state flags and have "gen" handshake with the file demon, and let the demon do all the file operations.
etable." In Wavetable mode, the channel RAM is used as a real RAM, not a FI FO, and the wave gen makes repetitive waveforms by looping through an arbit rary region of RAM. In that mode, the user can specify a phase shift and ch ange it on the fly.
Another asynchronous behavior coupling with real time requirements of the h ardware.
oth, invent the command line interfaces, and explain them both.
Sometimes it's hard to ask hardware engineer to do software engineering.
PS: "file daemon" should be in the kernel device driver.
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.