Thank you all.
I tried running 'fw_printenv -n hw_rev' in Pavel's OS image, but 'fw_printenv' is not found. I tried apt-get install u-boot-tools next, but 'fw_printenv' is missing still.
P.S. I installed libubootenv-tool with fw_printenv there, but fw_printenv returns 'Configuration file wrong or corrupted'
SD card image with Debian 8.0, Red Pitaya web server and SDK
-
- Posts: 106
- Joined: Thu Sep 03, 2015 6:56 pm
-
- Posts: 106
- Joined: Thu Sep 03, 2015 6:56 pm
Re: SD card image with Debian 8.0, Red Pitaya web server and SDK
Pavel,
Could you please clarify how one should correctly interpret 'sts_data' output in 'axis_osciloscope.v'?
My understanding of the protocol is that up until 'pre_data' samples are collected and the 'trg_flag' is set, the number of samples recorded so far is stored in 'int_cntr_reg'. Then after 'pre_data' samples are collected and the 'trg_flag' is set, the int_cntr_reg value is stored in 'int_addr_reg' and 'int_cntr_reg' is reset to the sum of 'pre_data' and last 6 bits of 'int_cntr_reg' (I don't get why the last 6 bits added though), after which the rest of the points up to tot_data is recorded.
When I try to use the 'int_addr_reg' part of the 'sts_data' to calculate the trigger position in relation to the start of the ram buffer, I get pretty close, but i miss by a few hindered points (out 0f 256MB buffer), and the error size depends on the pre_data value.
Could you please clarify how one should correctly interpret 'sts_data' output in 'axis_osciloscope.v'?
My understanding of the protocol is that up until 'pre_data' samples are collected and the 'trg_flag' is set, the number of samples recorded so far is stored in 'int_cntr_reg'. Then after 'pre_data' samples are collected and the 'trg_flag' is set, the int_cntr_reg value is stored in 'int_addr_reg' and 'int_cntr_reg' is reset to the sum of 'pre_data' and last 6 bits of 'int_cntr_reg' (I don't get why the last 6 bits added though), after which the rest of the points up to tot_data is recorded.
When I try to use the 'int_addr_reg' part of the 'sts_data' to calculate the trigger position in relation to the start of the ram buffer, I get pretty close, but i miss by a few hindered points (out 0f 256MB buffer), and the error size depends on the pre_data value.
-
- Posts: 801
- Joined: Sat May 23, 2015 5:22 pm
Re: SD card image with Debian 8.0, Red Pitaya web server and SDK
fw_printenv requires the following line in /etc/fw_env.config:
Here is the code that I use to read the oscilloscope data in the MCPHA project:
Code: Select all
/sys/bus/i2c/devices/0-0050/eeprom 0x1800 0x0400
Code: Select all
start = sts_data >> 1;
start = (start - pre) & 0x007FFFFF;
if(start + tot <= 0x007FFFFF)
{
if(send(sock_client, ram + start * 4, tot * 4, MSG_NOSIGNAL) < 0) break;
}
else
{
if(send(sock_client, ram + start * 4, (0x007FFFFF - start) * 4, MSG_NOSIGNAL) < 0) break;
if(send(sock_client, ram, (start + tot - 0x007FFFFF) * 4, MSG_NOSIGNAL) < 0) break;
}
-
- Posts: 106
- Joined: Thu Sep 03, 2015 6:56 pm
Re: SD card image with Debian 8.0, Red Pitaya web server and SDK
Pavel,
Thank you for all the help so far.
In the old debian version I used to create /etc/rc.local to cofigure the PL and start a TCP server middleware following your original suggestion.
Is it still a reliable method or should I use systemd approach with your latest image?
Thank you for all the help so far.
In the old debian version I used to create /etc/rc.local to cofigure the PL and start a TCP server middleware following your original suggestion.
Is it still a reliable method or should I use systemd approach with your latest image?
-
- Posts: 106
- Joined: Thu Sep 03, 2015 6:56 pm
Re: SD card image with Debian 8.0, Red Pitaya web server and SDK
I did some testing with my code and I went and did some more testing with a slightly modified 'adc_recorder_trigger' project, where I just removed all the filtering and recorded ADC stream into RAM at 125 MSPS. It appears to me that the oscilloscope module accumulates a trigger position error in relation to RAM writer memory position the longer the wait between the start of the adc_recorder_trigger app and the arrival of the hardware trigger. I recorder trigger voltage on CH1 and plotted a few test runs with different delay times. I also tested for missing samples in case of possible buffer overflow by recording a ~12.5 MHz sine wave and looking for phase jumps, and I did not see any. I wonder if you might have time to take a look, perhaps I did not use it right.
Here's a plot of the trigger position in recorded stream for different delay times between the start of the app and the hardware trigger:
The modified block_design.tcl
Code: Select all
# Create clk_wiz
cell xilinx.com:ip:clk_wiz pll_0 {
PRIMITIVE PLL
PRIM_IN_FREQ.VALUE_SRC USER
PRIM_IN_FREQ 125.0
PRIM_SOURCE Differential_clock_capable_pin
CLKOUT1_USED true
CLKOUT1_REQUESTED_OUT_FREQ 125.0
USE_RESET false
} {
clk_in1_p adc_clk_p_i
clk_in1_n adc_clk_n_i
}
# Create processing_system7
cell xilinx.com:ip:processing_system7 ps_0 {
PCW_IMPORT_BOARD_PRESET cfg/red_pitaya.xml
PCW_USE_S_AXI_ACP 1
PCW_USE_DEFAULT_ACP_USER_VAL 1
} {
M_AXI_GP0_ACLK pll_0/clk_out1
S_AXI_ACP_ACLK pll_0/clk_out1
}
# Create all required interconnections
apply_bd_automation -rule xilinx.com:bd_rule:processing_system7 -config {
make_external {FIXED_IO, DDR}
Master Disable
Slave Disable
} [get_bd_cells ps_0]
# Create xlconstant
cell xilinx.com:ip:xlconstant const_0
# Create proc_sys_reset
cell xilinx.com:ip:proc_sys_reset rst_0 {} {
ext_reset_in const_0/dout
dcm_locked pll_0/locked
slowest_sync_clk pll_0/clk_out1
}
# ADC
# Create axis_red_pitaya_adc
cell pavel-demin:user:axis_red_pitaya_adc adc_0 {
ADC_DATA_WIDTH 14
} {
aclk pll_0/clk_out1
adc_dat_a adc_dat_a_i
adc_dat_b adc_dat_b_i
adc_csn adc_csn_o
}
# Create axis_gpio_reader
cell pavel-demin:user:axis_gpio_reader gpio_0 {
AXIS_TDATA_WIDTH 8
} {
gpio_data exp_p_tri_io
aclk pll_0/clk_out1
}
# Create axi_hub
cell pavel-demin:user:axi_hub hub_0 {
CFG_DATA_WIDTH 192
STS_DATA_WIDTH 64
} {
S_AXI ps_0/M_AXI_GP0
aclk pll_0/clk_out1
aresetn rst_0/peripheral_aresetn
}
# Create port_slicer
cell pavel-demin:user:port_slicer slice_0 {
DIN_WIDTH 192 DIN_FROM 0 DIN_TO 0
} {
din hub_0/cfg_data
}
# Create port_slicer
cell pavel-demin:user:port_slicer slice_1 {
DIN_WIDTH 192 DIN_FROM 1 DIN_TO 1
} {
din hub_0/cfg_data
}
# Create port_slicer
cell pavel-demin:user:port_slicer slice_2 {
DIN_WIDTH 192 DIN_FROM 16 DIN_TO 16
} {
din hub_0/cfg_data
}
# Create port_slicer
cell pavel-demin:user:port_slicer slice_3 {
DIN_WIDTH 192 DIN_FROM 63 DIN_TO 32
} {
din hub_0/cfg_data
}
# Create port_slicer
cell pavel-demin:user:port_slicer slice_4 {
DIN_WIDTH 192 DIN_FROM 79 DIN_TO 64
} {
din hub_0/cfg_data
}
# Create port_slicer
cell pavel-demin:user:port_slicer slice_5 {
DIN_WIDTH 192 DIN_FROM 95 DIN_TO 80
} {
din hub_0/cfg_data
}
# Create port_slicer
cell pavel-demin:user:port_slicer slice_6 {
DIN_WIDTH 192 DIN_FROM 127 DIN_TO 96
} {
din hub_0/cfg_data
}
# Create port_slicer
cell pavel-demin:user:port_slicer slice_7 {
DIN_WIDTH 192 DIN_FROM 159 DIN_TO 128
} {
din hub_0/cfg_data
}
# Create port_slicer
cell pavel-demin:user:port_slicer slice_8 {
DIN_WIDTH 192 DIN_FROM 175 DIN_TO 160
} {
din hub_0/cfg_data
}
# Create axis_variable
cell pavel-demin:user:axis_variable rate_0 {
AXIS_TDATA_WIDTH 16
} {
cfg_data slice_8/dout
aclk pll_0/clk_out1
aresetn rst_0/peripheral_aresetn
}
# Create axis_variable
cell pavel-demin:user:axis_variable rate_1 {
AXIS_TDATA_WIDTH 16
} {
cfg_data slice_8/dout
aclk pll_0/clk_out1
aresetn rst_0/peripheral_aresetn
}
# Create axis_trigger
cell pavel-demin:user:axis_trigger trig_0 {
AXIS_TDATA_WIDTH 8
AXIS_TDATA_SIGNED FALSE
} {
S_AXIS gpio_0/M_AXIS
pol_data slice_2/dout
msk_data slice_4/dout
lvl_data slice_5/dout
aclk pll_0/clk_out1
}
# Create axis_packetizer
cell pavel-demin:user:axis_oscilloscope scope_0 {
AXIS_TDATA_WIDTH 32
CNTR_WIDTH 23
} {
S_AXIS adc_0/M_AXIS
run_flag slice_1/dout
trg_flag trig_0/trg_flag
pre_data slice_6/dout
tot_data slice_7/dout
aclk pll_0/clk_out1
aresetn slice_0/dout
}
# Create xlconstant
cell xilinx.com:ip:xlconstant const_1 {
CONST_WIDTH 18
CONST_VAL 262143
}
# Create axis_ram_writer
cell pavel-demin:user:axis_ram_writer writer_0 {
ADDR_WIDTH 18
AXI_ID_WIDTH 3
AXIS_TDATA_WIDTH 32
FIFO_WRITE_DEPTH 1024
} {
S_AXIS scope_0/M_AXIS
M_AXI ps_0/S_AXI_ACP
min_addr slice_3/dout
cfg_data const_1/dout
aclk pll_0/clk_out1
aresetn slice_0/dout
}
# Create xlconcat
cell xilinx.com:ip:xlconcat concat_0 {
NUM_PORTS 2
IN0_WIDTH 32
IN1_WIDTH 32
} {
In0 scope_0/sts_data
In1 writer_0/sts_data
dout hub_0/sts_data
}
-
- Posts: 106
- Joined: Thu Sep 03, 2015 6:56 pm
Re: SD card image with Debian 8.0, Red Pitaya web server and SDK
I also made a small ram streaming test using free-running counter, a hybrid of adc_recorder_trigger and writer_test, but with non-blocking counter increment to check for data loss at 125 MSPS. I do not see any data loss so far, but I do notice the trigger position reported by oscilloscope creeps forwards in the same manner.
-
- Posts: 801
- Joined: Sat May 23, 2015 5:22 pm
Re: SD card image with Debian 8.0, Red Pitaya web server and SDK
Thank you for testing the adc_recorder_trigger project. I do not see why it is behaving this way at the moment.
What version of the adc_recorder_trigger project and IP cores are you using? From my github repository or from yours?
What version of the adc_recorder_trigger project and IP cores are you using? From my github repository or from yours?
-
- Posts: 106
- Joined: Thu Sep 03, 2015 6:56 pm
Re: SD card image with Debian 8.0, Red Pitaya web server and SDK
My test projects are in the 'develop' branch of the https://github.com/ffb-LANL/red-pitaya-notes. It is a fork of your red pitaya notes repository. The 'master' branch of your repository was last upstream merged into my 'develop' branch around Nov 30 2023.
The project 'adc_recorder_trigger_test' is the modified version of your 'adc_recorder_trigger', where I removed filtering to test 125 MSPS streaming. In the project 'recorder_trigger_memtest' i replaced adc module with incremental counter to check for data loss.
The project 'adc_recorder_trigger_test' is the modified version of your 'adc_recorder_trigger', where I removed filtering to test 125 MSPS streaming. In the project 'recorder_trigger_memtest' i replaced adc module with incremental counter to check for data loss.
-
- Posts: 106
- Joined: Thu Sep 03, 2015 6:56 pm
Re: SD card image with Debian 8.0, Red Pitaya web server and SDK
I run some more diagnostics with recorder_trigger_memtest and it looks like the reported osciloscope position matches the stream byte counter, but the writer position lags behind increasingly as the time between the app start and the trigger event increases.
-
- Posts: 106
- Joined: Thu Sep 03, 2015 6:56 pm
Re: SD card image with Debian 8.0, Red Pitaya web server and SDK
I've also created a 256M recorder test project, 'recorder_trigger_memtest_256M' and tested with record as long as ~200Mb and there I also see that the oscilloscope trigger position counter matches sample count (the later adjusted for buffer wraps), but the data in the RAM is increasingly behind. I'm not sure what is a correct way to quantify the delay, but on average is it about 500-1k sample delay per full buffer of samples streamed through. I tested delays from sub-second to a few minutes.
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: No registered users and 9 guests