Redpitaya Forum

Do I interpret it correctly that you have taken the top 32MB of RAM out of the linux address space and use that as the shared mem ?

Yes, you are right. For simplicity, I'm using a free memory block at the end of the RAM address range for DMA without a device driver nor an additional scatter/gather complexity.

I found this idea in the following article:

http://blog.fakultaet-technik.de/develo ... oot-files/

Later I found that a similar approach is used in the Linux kernel and know as Contiguous Memory Allocator (CMA). Here is how it reports its status at the very beginning of the Linux boot:

For the shared memory between the processes I'm using the following approach:

http://man7.org/tlpi/code/online/dist/m ... map.c.html

@pavel: i guess you could use these 2 drivers as well (in case if you need dma between linux and fpga)?
https://github.com/bmartini/zynq-xdma
https://github.com/bmartini/zynq-axis

Hi Arnold,

I've already seen the two projects that you propose to use. I'm not using them because they are too complicated for my simple needs.

If you want to continue this discussion about the DMA IP cores and DMA Linux drivers, then let's move it to a new forum thread.

Cheers,

Pavel

Hi!

Does anyone have any idea regarding my previous post?

Also, I'm wondering if it is possible to change the size of packets that are being sent over network. I looked over your source but didn't find it... (currently, it seems that packets are 1500B length).
I was able to make a LabView program that shows my signal continuously, but it seems like I can't go under decimation 128 (and I'd like to be at 8!). I think that might help, 'cause the problem seems to be with the computers RAM and not RedPitaya.

Regarding the disturbances you described previously, I have no idea what could cause them, neither have I seen this behaviour myself yet. I am currently doing more thorough tests of the file output path and will let you know if anything comes up.

The packet size of 1500B comes about from the MTU (maximum transmission unit) that standard ethernet frames can have. The Red Pitaya can not send larger (so-calles jumbo) frames, because the ZYNQ's embedded ethernet controller does not support them.

In case you were thinking of using smaller frames, that could be accommodated. Just give buffers of the desired size to the send() function.

Well, it seems like my problem's gone. I guess I was dealing with datas the wrong way.
Anyway, this is fixed now and I can acquire the way I want to, by writing a file on RP and then reading it over network.

BTW, via UDP, I'm able to send datas at 60 MB/s (decimation 1), but my computer does'nt get any datas under decimation 256... (I guess it's a network related problem, or regarding my computer?). Decimation 256 => 1 MB/s, which is already a good rate!
That's just FYI, since I solved my problem, but thank you for your help!

Simon

Hi,
i'm currently developing a backscattering device using the transducers available in the HC-SR04 module. I have already modified the generate app to generate a burst with changing frequency (chirp). Now comes the part that I need to receive the data in the receiver.
Is there any chance that we can set the trigger through the FPGA register?

Thanks
Pereira

Hello,
how do you estimate the effort needed to implement continuous analog output, similar to the input functionality discussed in this thread. I think the main effort is in extending the fpga code, while on the ARM side replicating the receive solution should be straight forward. Maybe it could be possible to map the transmit and receive memory such, that the transmit and receive buffer addresses are timely synchronized. Maybe it is the easiest way to replace the current transmit mechanism or do you see a good chance to preserve compatibility with the redpitaya master image.
Further I would like to extend this mechanism to digital output.

thanks for your suggestions

jpereira94 wrote:Is there any chance that we can set the trigger through the FPGA register?

Sorry for being quite late to answer. I don't understand what you mean by "set the trigger" and which FPGA register you are referring to.

jneumann wrote:how do you estimate the effort needed to implement continuous analog output, similar to the input functionality discussed in this thread.

I already tried some preliminary fpga modifications in that direction. It is slightly more complicated to read from external RAM with an AXI master, but doable.

do you see a good chance to preserve compatibility with the redpitaya master image

Unlike the ADC solution, where you can operate both data paths side by side, for the DAC you'd have either one source of samples or the other, but they'd still be able to live in the same bitstream. So, you wouldn't need to reprogram the fpga to switch between them.