Accessing BRAM data from /dev/mem of RedPitaya

Applications, development tools, FPGA, C, WEB
adiana007
Posts: 21
Joined: Mon Jun 05, 2023 11:44 am

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by adiana007 » Thu Jun 29, 2023 1:18 pm

Hey Pavel,
You can send N*18750 samples to axis_ram_writer
When a trigger arrives in the FPGA, I start buffering the data until the count reaches 19200, and let's say I do it until I buffer 10*19200 (10 such triggers received). Then while I start sending these to the axis_ram_writer, how will the server know when to start capturing the data (the point where I start sending 5*19200 to axis_ram_writer), should I send a flag from PL to server code via status register at the point where I start sending 5*19200 to axis_ram_writer?. If not, what would be the best way to know from the PS side on when to capture the right data that I send, because with the current approach, server code keeps sending data to client, whenever it is run (this is what I meant by synchronisation, sorry if I was wrong in my terminology).

I guess the problem I'm facing is in communicating to PS on when to start reading the data.
The server code also needs to be updated.
I used the server code that's has the updated limit values in the GitHub.

pavel
Posts: 799
Joined: Sat May 23, 2015 5:22 pm

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by pavel » Thu Jun 29, 2023 1:31 pm

When a trigger arrives in the FPGA, I start buffering the data until the count reaches 19200, and let's say I do it until I buffer 10*19200 (10 such triggers received).
I still do not understand why you want all this extra complexity.

Once the trigger arrives, start counting them and sending them one by one to axis_ram_writer. Once the counter reaches 19199, stop sending samples and wait for the next trigger.

adiana007
Posts: 21
Joined: Mon Jun 05, 2023 11:44 am

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by adiana007 » Thu Jun 29, 2023 1:53 pm

Once the counter reaches 19199, stop sending samples and wait for the next trigger.
I understand from the PL side, but in server code the *rx_ctrl(position) should be aligned with start address of the trigger captured data. But when we access the *rx_ctrl it might not be the same as it keeps running. So how should I capture from PS server code?
Last edited by adiana007 on Thu Jun 29, 2023 3:46 pm, edited 2 times in total.

pavel
Posts: 799
Joined: Sat May 23, 2015 5:22 pm

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by pavel » Thu Jun 29, 2023 3:37 pm

but in server code the *rx_ctrl(position) should be aligned with start address of the trigger captured data.
I still do not understand why you need this alignment.

Just use the connection between axis_ram_writer and the output file on the computer as a pipeline. You write X (19200 * 1000000) bytes on one side (axis_ram_writer) and you read the same X (19200 * 1000000) bytes on the other side (output file).

adiana007
Posts: 21
Joined: Mon Jun 05, 2023 11:44 am

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by adiana007 » Thu Jun 29, 2023 3:46 pm

Just giving you some description of how I have been using your design as blackbox, I write a logic that starts a counter and counts till N, after which the count value goes to 1 (the counter is the data we are inputting to axis_ram_writer. I am passing the trigger (that initiates the counter) to PS through Status register. In PS, I made the following modifications to the server code. I included an if block inside the second while loop

Code: Select all

if (*trig & 0x1 || trig_rcvd)
where *trig is obtained from status register, trig_rcvd is to ensure that once I enter into the if block I make sure one set of data is sent when the second if statement goes to true

Code: Select all

if ((limit > 0 && position > limit) || (limit == 0 && position < 4 * 1024))
my output file from client has constant set of 1, which is when no counter data is being sent. So, I suspect I am not capturing at the exact point of trigger, I would like to know your thoughts and approach on the same

pavel
Posts: 799
Joined: Sat May 23, 2015 5:22 pm

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by pavel » Thu Jun 29, 2023 4:31 pm

I have just rebuilt and tested the latest version of the adc_test project. It works for me without any problem.

Here is the client program that I use to write the ADC samples to a file:

Code: Select all

/*
command to compile:
gcc adc-test-client.c -o adc-test-client
*/

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/select.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define TCP_ADDR "192.168.1.100"
#define TCP_PORT 1001

int main(int argc, char**argv)
{
  FILE *output;
  int i, sock;
  struct sockaddr_in addr;
  char buffer[256*1024];

  output = fopen("output.dat", "wb");

  if((sock = socket(AF_INET, SOCK_STREAM, 0)) < 0)
  {
    perror("socket");
    return 1;
  }

  memset(&addr, 0, sizeof(addr));
  addr.sin_family = AF_INET;
  addr.sin_addr.s_addr = inet_addr(TCP_ADDR);
  addr.sin_port = htons(TCP_PORT);

  if(connect(sock, (struct sockaddr *)&addr, sizeof(addr)) < 0)
  {
    perror("connect");
    return 1;
  }

  for(i = 0; i < 256*4; ++i)
  {
    recv(sock, buffer, 256*1024, MSG_WAITALL);
    fwrite(buffer, 1, 256*1024, output);
  }
}
I also use the following command to generate a 10 Hz sine waveform and connect OUT1 to IN1.

Code: Select all

./gen 1 32766 10
I think that before trying to make any changes to the adc_test project, you better try running the unmodified version of the FPGA configuration, server code and client code and check if the output file contains a reasonably looking signal.

adiana007
Posts: 21
Joined: Mon Jun 05, 2023 11:44 am

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by adiana007 » Fri Jun 30, 2023 6:11 am

Hey Pavel,

I understand your implementation, I tested with counter input, and the data is sequential which verifies the continuity, same as verifying by providing a known sine signal input. But the issue I'm facing is that say I provide a sine signal that has 300us ON and 650us OFF period. Now, along with the signal I also receive a GPIO trigger that has the same 300us ON and 650us OFF duration. In the FPGA side, I can actuate this mechanism of starting the capture of the signal corresponding to 300us only when positive edge of the trigger arrives and sending the data to axis_ram_writer. But my doubt is how will the server code get to know that positive edge of trigger has been detected and the right data has been sent through the axis_ram_writer?. Because I have to initiate capture from the server program only when data corresponding to ON period (300us) is being sent to axis_ram_writer.

Currently when I try starting the capture from server program by passing the trigger through Status register, I find that I'm not reading the data exactly from start of the trigger.

pavel
Posts: 799
Joined: Sat May 23, 2015 5:22 pm

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by pavel » Fri Jun 30, 2023 8:41 am

But my doubt is how will the server code get to know that positive edge of trigger has been detected and the right data has been sent through the axis_ram_writer?
I think the server code does not need to know anything about the trigger. The server code only sees right data because the FPGA code sends only right data to axis_ram_writer.

The server code is constantly waiting for data. Once it has enough data (256 kB) to send, it sends it to the client.

This discussion is getting more and more tiresome for me. Since the beginning of this thread and even earlier by e-mail, you start by asking me for advice, then you refuse it and you even refuse to do any simple thinking or calculation. Your requirements keep changing, which makes understanding your project quite difficult for me. After all, it is your job and not mine to implement this project. So, do as you see fit and let's end this fruitless discussion here.

adiana007
Posts: 21
Joined: Mon Jun 05, 2023 11:44 am

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by adiana007 » Fri Jun 30, 2023 9:30 am

The server code only sees right data because the FPGA code sends only right data to axis_ram_writer.
I guess I understand the issue now, currently when a trigger comes, in the PL side, I start sending the counter data, but after sending say 19199 samples, I start sending a constant 1. But instead I shouldn't send anything (if I'm not wrong), so does that mean I have to pause the address increments as soon as the first 19199 samples have been written and continue incrementing them when next trigger comes?. Request you to kindly validate me in this approach

Code: Select all

int_addr_next = int_addr_reg + 1'b1;
you start by asking me for advice, then you refuse it and you even refuse to do any simple thinking or calculation.
I'm very sorry if there was a misunderstanding, I'm doing all my trials on data capture based on your replies to my queries, I never meant to refuse any of them.
Your requirements keep changing, which makes understanding your project quite difficult for me.
Only the specifications of data capture has downgraded from what was previously mentioned (data rate calculations you helped me with). Apart from that my project has always been triggered data acquisition. I would like to apologise if there were any miscommunications from my end.

sslerose
Posts: 35
Joined: Sat Nov 26, 2022 12:43 am

Re: Accessing BRAM data from /dev/mem of RedPitaya

Post by sslerose » Thu Jul 20, 2023 2:15 am

adiana007 wrote:
Thu Jun 15, 2023 5:02 pm
There was a misunderstanding from my side, as I was following on the LED pattern provided by the RedPitaya, but now I'm clear and also able to ssh and setup.

Could you happen to let me know your process for creating the image and actually ssh'ing into the Red Pitaya?

Thanks in advance.

Post Reply
jadalnie klasyczne ekskluzywne meble wypoczynkowe do salonu ekskluzywne meble tapicerowane ekskluzywne meble do sypialni ekskluzywne meble włoskie

Who is online

Users browsing this forum: Bing [Bot] and 88 guests