Re: New feature: high speed continuous recording
Posted: Wed Oct 22, 2014 7:43 pm
Thank You for the explanation ... i'm looking forward to new feature ...
Redpitaya users forum
https://forum.redpitaya.com/
Code: Select all
cat /red/rpad0 > test_ddrdump.txt
Code: Select all
%% plot signal
%% first clean up
close all; clear all; clc;
%% Initial variables
file_dir = pwd;
file_name = [ file_dir '\' 'test_ddrdump.txt'];
% some variables to scale the later plot
n_plot_points = 200 ;
dec_factor = 1;
sample_rate = 125e6 / dec_factor;
%% read data from file, interpret as unsigned int16
tic
fid = fopen(file_name);
adc = fscanf(fid, '%x');
fclose (fid);
toc
% reformat to matrix (1MSample, 2 channels)
tic
adc = reshape(adc,1024*1024,2);
toc
% transfer from "misinterpreted" two's complement to double and scale to voltage
tic
adc (:,1) = tc2dec(adc(:,1),14) /2^12;
adc (:,2) = tc2dec(adc(:,2),14) /2^12;
toc
%% plot first n_plot_points data points
% tic
% time scaling
n_points = size (adc(:,1));
time = [0:1/sample_rate: (n_points-1) * 1/sample_rate];
% ploting
plot (time(1:n_plot_points),adc(1:n_plot_points,1),'b');
hold on;
plot (time(1:n_plot_points),adc(1:n_plot_points,2),'r');
hold off;
xlabel ('time [s]');
ylabel ('Voltage [V]');
% toc
Code: Select all
%% modified from http://www.mathworks.nl/matlabcentral/fileexchange/5485-two-s-complement-for-matlab
%% modified example from Hassan Naseri
% input as int16 val, but wrong bit alligned, output as double
function value = tc2dec(val,N)
% val = bin2dec(bin); % removed from original example, cause we have dec values
% modified for matrix calculation
y = sign(2.^(N-1)-val).*(2.^(N-1)-abs(2.^(N-1)-val));
if ((y == 0) && (val ~= 0))
value = -val;
else
value = y;
end
end
% reverse function, too export the data backwards in two's complement
function value = dec2tc(dec, N)
value = dec2bin(mod((dec),2^N),N);
end
The ddr_[ab]_base registers already function in that way, they are only read when the ddr_[ab]_end mark is reached or an address (re)load is signaled via the ddr_control register. They can be preloaded with the next buffer address at any time in between.Do you think it would be good idea to implement some kind of ddr_next_addr thing that could be loaded before the previous buffer finishes?
This depends on whether you still want to run linux on the device or not. In the former case, it is infeasible to use all of the available external RAM; however, the kernel can be told to only use a certain portion of RAM via its command line parameters (but I guess you knew that already). Thus, a sizable chunk - say 256MB - could be set aside for the buffers while still running a fully fledged OS. If you really wanted to use all the available external RAM, a bare metal application with network support could run from OCM.Also, if you could share how to extend the buffer to full memory, this would be interesting to know.
One of the next things on my list is interrupt support, the tracking of ddr_curr was just a stop-gap measure to arrive at a working solution as quickly as possible.... and also would not require as much real time work to track the status of ddr_curr_addr.