redpitaya / redpitaya

Red Pitaya Ecosystem and Applications

What is Red Pitaya?

Credit size mobile IoT hardware & software platform that replaces many expensive laboratory measurements and control instruments. Open-source software examples, easy interfacing with sensors and actuators, and the possibility to control it using Python, Jupyter, MATLAB or LabVIEW & C, makes it a perfect tool in education or rapid product development.

Where to get one?

Red Pitaya boards can be purchased @ RedPitaya online store. To better understand how product specifications differ from each other we suggest you look at the hardware specifications comparison table & Supported features and apps by Red Pitaya model table.

How can I start using it?

First step is to connect to your device by following the quick start guide.

How to start using Red Pitaya as a test & measurement instrument?

Once you connect to Red Pitaya from WEB browser it can be immediately used as:

• Oscilloscope
• Spectrum analyzer
• Signal generator
• Bode analyzer
• LCR meter
• Vector Network Analyzer
• and more... There are also many other (contributed) applications available on RedPitaya marketplace. For more information about RedPitaya apps click here.

How to start using Red Pitaya as SDR (software defined radio)?

SDR support for RedPitaya is done and maintained by Pavel Demin. The best place to get the latest software from is Pavel’s repository.

How to start programming Red Pitaya or developing your own applications?

There are several ways to program / develop with Red Pitaya.

1. Remote control / programming

   Remote control can be done by using most popular rapid prototyping development tools MATLAB, LABview, SCILAB or Python remotely. There are several examples available.

2. Programming Red Pitaya directly from WEB browser / Python Red Pitaya can be programmed in Python directly from the WEB browser using Jupyter.

3. C/C++ programming

RedPitaya hardware features can be easily accessed through C APIs. Many starting examples are available at this link.

4. FPGA programming Information on how to compile Red Pitaya open source FPGA code is here.

5. Creating own WEB applications Instructions on how to create your own Red Pitaya WEB applications can be found here.

How to interface Red Pitaya with other hardware or sensors?

Besides fast analog inputs and outputs Red Pitaya comes with an extension connector that enables users to interface with other hardware devices or sensors over standard i2c, UART, SPI interfaces or additional slow analog inputs and outputs and digital GPIOs.

There are two main extension possibilities:

1. Using already available sensor extension module by RedPitaya Sensors extension module provides direct connection to GroveSensors (e.g. Temperature sensor, Motion sensor,Touch sensor, Button, Switch, Tilt, Potentiometer, Light sensor, Air quality sensor, Vibration sensor, Moisture sensor, Water sensor, Alcohol sensor, Barometer not supported at the moment, Sound sensor, UV sensor, Accelerometer, Relay). Sensor extension module also provide compatibility with Arduino extension modules. More examples and information can be found at this link.

2. Creating own add on module that connects to extension connector For more information about extension connector click here

How to start teaching with RedPitaya?

Teaching lectures / material. Red Pitaya Knowledge Base

redpitaya's Issues

Issue with OS/debian/build.sh, no space left on device

When I run it here's the output:

Setting up libcunit1-ncurses-dev (2.1-3-dfsg-2) ...
Processing triggers for libc-bin (2.23-0ubuntu3) ...
root@ThinkPad-11e:/# 
root@ThinkPad-11e:/# exit
'OS/debian/overlay/etc/profile.d/profile.sh' -> 'root/etc/profile.d/profile.sh'
'OS/debian/overlay/etc/profile.d/alias.sh' -> 'root/etc/profile.d/alias.sh'
'OS/debian/overlay/etc/profile.d/redpitaya.sh' -> 'root/etc/profile.d/redpitaya.sh'
root@ThinkPad-11e:/# echo root:root | chpasswd
root@ThinkPad-11e:/# apt-get clean
root@ThinkPad-11e:/# history -c
root@ThinkPad-11e:/# exit
cat: write error: No space left on device

Also strangely, the images which are being downloaded are named differently and have different sizes.

-rw-r--r--  1 root root 3.5G Oct 14 11:47 redpitaya_ubuntu_11-44-42_14-Oct-2016.img
-rw-r--r--  1 root root  44M Oct 14 11:47 redpitaya_ubuntu_11-44-42_14-Oct-2016.tar.gz
-rw-r--r--  1 root root 3.5G Oct 14 12:33 redpitaya_ubuntu_11-55-22_14-Oct-2016.img
-rw-r--r--  1 root root 261M Oct 14 12:33 redpitaya_ubuntu_11-55-22_14-Oct-2016.tar.gz

That might indicate that you should use http range requests that way if people's connection drops out or if the script restarts it won't re-download the same bytes.

• curl use the -r flag
• wget use the -c flag

FPGA Firmware

I tried to load the FPGA firmware using "red_pitaya_vivado_project.tcl", which runs the tcl file at
"x:\RedPitaya\fpga\prj\logic\ip\system.tcl".

Then the errors below appeared.

ERROR: [BD 41-237] Bus Interface property CLK_DOMAIN does not match between /axis_clock_converter_i1/S_AXIS(system_S_AXI_STR_RX1_aclk) and /S_AXI_STR_RX1(system_S_AXI_STR_RX2_aclk)
ERROR: [BD 41-237] Bus Interface property CLK_DOMAIN does not match between /M_AXI_STR_TX1(system_M_AXI_STR_TX1_aclk1) and /axis_clock_converter_o1/M_AXIS(system_M_AXI_STR_TX1_aclk)
ERROR: [BD 41-1031] Hdl Generation failed for the IP Integrator design C:/Users/EflyZhao/Documents/GitHub/RedPitaya/fpga/prj/project/redpitaya.srcs/sources_1/bd/system/system.bd

Did I load the right "system.tcl"?
What are the differences among the folders "logic", "logic_origin", "classic", "tft" and "v0.94" in "x:\RedPitaya\fpga\prj"?

SCPI: buffer overflow in RP_AcqSamplingRateHzQ()

In scpi-server/src/acquire.c RP_AcqSamplingRateHzQ() the return value to "ACQ:SRAT?" (usually "125000000 Hz") is printf'ed into a char[1] buffer.

This leads to the value being returned without linefeed and immediate closing of the connection.

Is there a reason for branching 0.95 from 0.94 ca. RC22 ?

I'd like to know if there are known problems with the release candidates 0.94 >RC22 that made you base the 0.95 release on RC22.

There have been several bugfixes and enhancements to master after RC22 that are missing from 0.95 . For example the cores are now limited to 500MHz again, tool dependency is back to Vivado 2015.2, and the AXI acquisition logic is broken with the 0.95 "stable" image.

Regards
Nils

make clean deletes SDK/include/lib...

after issuing

$ make -C SDK/ clean

git status reports

    deleted:    SDK/include/librp.so
    deleted:    SDK/include/libscpi.so
    deleted:    SDK/include/libscpi.so.0.3.0
    deleted:    SDK/include/rp.h

which results in a compilation error when running make

$ make -C SDK/
INSTALLING REDPITAYA SDK ZIP...

mkdir -p include
cp ../api-mockup/rpbase/src/rp.h ./include
cp: cannot stat ‘../api-mockup/rpbase/src/rp.h’: No such file or directory

can't configure FPGA clock frequency in v0.96

Dear Red Pitaya developers,

I've just tested the latest stable SD card image (red_pitaya_OS-v0.96-RC1-20-14_jul.img.zip) and found that the following device isn't available anymore:

/sys/devices/soc0/amba/f8007000.devcfg/fclk

I've also found that f8007000.devcfg is renamed to amba:fpga_bus@0/f8007000.devcfg with the following patch:
https://github.com/RedPitaya/RedPitaya/blob/master/patches/zynq-7000.patch

Unfortunately, amba:fpga_bus@0/f8007000.devcfg doesn't have any fclk entry.

My SDR applications require fclk to configure the FPGA clock with a slightly higher frequency (143 MHz).

Could you please add the fclk entries to one of the future versions of the default Red Pitaya device tree?

If I'm not mistaken, the following lines in zynq-7000.patch

  clocks = <&clkc 12>;
  clock-names = "ref_clk";

should be replaced with

  clocks = <&clkc 12>, <&clkc 15>, <&clkc 16>, <&clkc 17>, <&clkc 18>;
  clock-names = "ref_clk", "fclk0", "fclk1", "fclk2", "fclk3";

Best regards,

Pavel

IST RealProbe Flow & Oscilloscope 0.94-400 does not work

Just tested all the Bazaar applications with the latest SD card image (red_pitaya_OS_v0.94-RC16_21-Oct-2015.img.zip). All seem to work except "IST RealProbe Flow & Oscilloscope 0.94-400".

The error message is "Could not start the application".

I tried to uninstall/install it a couple of times but it didn't help.

Two axi_master with same ID

In the file FPGA/release1/fpga/code/rtl/red_pitaya_ps.v file there is mentioned that the same ID for two differtent axi_master is not OK.

I solved that issue with re-factoring the two different axi0_master and axi1_master to a new naming convention axi_master[1:0]. With that help a generate can be done on the instantiation of the axi_master.
PR follows ...

Greetings,
Uli

No FPGA Sources

It would be good if you made the FPGA source available as it would allow people to learn and improve upon what is already there.

Different interpretation of channel value in RP_GenTrigger(), RP_ParseChArgv(), rp_GenTrigger() and gen_Trigger()

I think I might have spotted a some bugs in the scpi-server application. They occur when setting the SOUR#:TRIG:IMM value.

As this is more an architectural/consistency kind of problem, I am unable write a patch resolving the issue.

1) RP_ParseChArgv allows a larger channel range than rp_channel_t can hold

When submitting the above command, we land in the following function (scpi-server/generate.c)

scpi_result_t RP_GenTrigger(scpi_t *context) {

    rp_channel_t channel;
    int result;

    if (RP_ParseChArgv(context, &channel) != RP_OK){
        return SCPI_RES_ERR;
    }
   ....

It parses the channel number with the help of RP_ParseChArgv (scpi-server/common.c) and assigns the parsed channel number to channel, which is a rp_channel_t enum. The problem is that RP_ParseChArgv checks whether the channel number is within the interval [0;3]. (MIN_CH==0 and MAX_CH==3). However, the rp_channel_t enum can only hold two values (RP_CH_1 and RP_CH_2). Moreover, RP_ParseChArgv subtracts 1 AFTER checking the range meaning that sending the command SOUR0:TRIG:IMM yields a channel number of -1.

int RP_ParseChArgv(scpi_t *context, rp_channel_t *channel){
  if(ch_usr[0] < MIN_CH || ch_usr[0] > MAX_CH){
    RP_LOG(LOG_ERR, "ERROR: Invalid channel number: %.*s\n", 50, context->param_list.cmd_raw.data);
  return RP_EOOR;
}

typedef enum {
    RP_CH_1, //!< Channel A
    RP_CH_2  //!< Channel B
} rp_channel_t;

2) The same value is interpreted as channel number and then as mask without proper conversion

According to the SCPI-Command-Documentation (.odt), the rp_channel_t enum and the variable names, the SCPI-Command as well as the scpi-command-handling functions assume that the supplied number corresponds a channel number. But the function rp_GenTrigger(int mask), to which this value is passed handles this value as a mask rather than a channel number. This can be seen when following the call path from RP_GenTrigger(scpi_t *context) -> rp_GenTrigger(int mask) -> gen_Trigger(int mask):

In RP_GenTrigger (scpi-server/generate.c), the supplied value is assumed to be a channel number:

scpi_result_t RP_GenTrigger(scpi_t *context) {

    rp_channel_t channel;
    int result;

    if (RP_ParseChArgv(context, &channel) != RP_OK){
        return SCPI_RES_ERR;
    }

    result = rp_GenTrigger(channel);
    if(result != RP_OK){
        RP_LOG(LOG_ERR, "*SOUR#:TRIG:IMM Failed to set immediate "
            "trigger: %s\n", rp_GetError(result));
        return SCPI_RES_ERR;
    }

    RP_LOG(LOG_INFO, "*SOUR#:TRIG:IMM Successfully set immediate trigger.\n");
    return SCPI_RES_OK;
}

But in the following functions (rpbase/rp.c and rpbase/gen_handler.c) the same number is interpreted as mask rather than a channel number:

int rp_GenTrigger(int mask) {
    return gen_Trigger(mask);
}

int gen_Trigger(int mask) {
    switch (mask) {
        case 1:
            ECHECK(gen_setGenMode(RP_CH_1, RP_GEN_MODE_BURST));
            return generate_setTriggerSource(RP_CH_1, RP_GEN_TRIG_SRC_INTERNAL);
        case 2:
            ECHECK(gen_setGenMode(RP_CH_2, RP_GEN_MODE_BURST));
            return generate_setTriggerSource(RP_CH_2, RP_GEN_TRIG_SRC_INTERNAL);
        case 3:
            ECHECK(gen_setGenMode(RP_CH_1, RP_GEN_MODE_BURST));
            ECHECK(gen_setGenMode(RP_CH_2, RP_GEN_MODE_BURST));
            return generate_simultaneousTrigger();
        default:
            return RP_EOOR;
    }
}

3) Different offset to encode the channels

gen_Trigger(int mask) assumes channels to be encoded as follows:

channel 1:     1
channel 2:     2
both channels: 3

The parse function RP_ParseChArgv as well as the rp_channel_t-enum encode channels as follows:

channel 1: 0
channel 2: 1

This leads to the problem that if you would actually want to trigger channel1 (as defined by rp_channel_t and parsed by RP_ParsechArgv you would have to send SOUR2:TRIG:IMM instead.

Build GNU/Linux ramdisk from sources

The GNU/Linux ramdisk should be built from sources instead of relying on staged binaries from Xilinx.

Error in SCPI BIN mode header

In scpi-server/3rdparty/libs/scpi-parser/libscpi/src/parser.c:

line 516 incorrectly:
result += writeBinHeader(context, size, sizeof(float));

should be:
result += writeBinHeader(context, size, sizeof(int16_t));

FPGA: Project creation fails due to missing system.tcl

Running "make project PRJ=test" for the current master results in an error

couldn't read file "ip/system.tcl": no such file or directory

I am new to FPGA programming, but I guess, the script is not being copied properly during project creation. What would be the correct system.tcl to use for a new project?

scpi signal generation

I'm running OS 0.96-86. There was a bug with the PWM generation using SCPI (http://forum.redpitaya.com/viewtopic.php?f=14&t=1044). Will it be fixed soon?

Cheers,
Alex

readme clarification

Hi,

could you please elaborate on the following that is written in the README.md:

Xilinx Vivado 2015.2 FPGA development tools. The SDK (bare metal toolchain) must also be installed, be careful during the install process to select it. Preferably use the default install location.

It is not clear to me what to download, if it is really necessary to register there, etc. I am having difficulties finding FPGA and also have no clue what metal toolchain refers to. I hope it is not necessary for me to learn everything about vivado, because I rather concentrate on the pitaya...

Thanks for the clarification,

Bernd

possibility to configure a default IP address if there is no DHCP server

Hello,

Would it be possible to add possibility to configure a default IP address if there is no DHCP server as it was done in the earlier versions of the Red Pitaya ecosystem and as it's described on the following wiki page:
http://wiki.redpitaya.com/index.php?title=User_Manual#Network_DHCP_configuration

This functionality was already requested several times on the Red Pitaya forum:
http://forum.redpitaya.com/viewtopic.php?f=7&t=568#p2665
http://forum.redpitaya.com/viewtopic.php?t=1040&p=3582#p3582
http://forum.redpitaya.com/viewtopic.php?t=1036&p=3581#p3581

To configure a default IP address if there is no DHCP server, the following lines should be added to /etc/dhcp/dhclient.conf on the Debian based system:

timeout 20;

lease {
  interface "eth0";
  fixed-address 192.168.1.100;
  option subnet-mask 255.255.255.0;
  renew 2 2030/1/1 00:00:01;
  rebind 2 2030/1/1 00:00:01;
  expire 2 2030/1/1 00:00:01;
}

Best regards,

Pavel

Please create a tag for version 0.95

Dear RedPitaya developers,

The version number of the SD image zip file downloadable from redpitaya.com is 0.95.

Looking at the RedPitaya github repository, it's not clear what code is used to build this SD image zip.

Could you please create a tag corresponding to this version?

Kind regards,

Pavel

AUTO button: Error while sending data (E3)

Release 0.90, RM-3707

When AUTO button is pressed and signal applied to one of the input channels is at ~1 Hz, the application fails with "Error while sending data (E3)" error.

path to toolchain external path is hardcoded into OS/buildroot/config

Ideally this could be patched using environmental variables during build/configure time. At the very least, it should be noted in the INSTALL file (similarly to /var/git/*.git directories) that this must be changed if the toolchain is elsewhere.

Source code from scpi-server

Please supply it! scpi-server doesn't work on Ubuntu. :(

AUTO button: Wrong number of periods

Release 0.90, RM-3724

When AUTO button is pressed and signal applied to one of the input channels is at the border cases regarding time units (1.5 of signal period close to 1s or 1ms), the number of periods displayed in the diagram differs significantly from the expected ~1.5.

add USB ID 0bda:8179

Hi,

I have a TP-Link TL-WN725N v2, which uses the RTL8188EUS chipset and should therefore work out of the box, but it doesn't because its USB ID 0bda:8179 is unknown to the RedPitaya ecosystem.

Could you please add the required entries to OS/linux/patches/add_rtl8192cu.patch and upload a new ecosystem build? I haven't got the time just now to set up the build environment required for doing this.

Thanks!

Cannot build EcoSystem - make: *** No rule to make target 'fpga.zip', needed by 'build/fpga'

Hello,

I am trying to build the RedPitaya EcoSystem and it is failing on a build rule. Is the build tree broken? I am building on an Ubuntu 16.04 Machine. Vivado is 2016.4

make -f Makefile.x86 install

...
...

cp tmp/linux-xlnx-redpitaya-v2016.2/arch/arm/boot/uImage build
curl -L https://github.com/Xilinx/device-tree-xlnx/archive/xilinx-v2016.4.tar.gz -o dl/device-tree-xlnx-xilinx-v2016.4.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   139    0   139    0     0    181      0 --:--:-- --:--:-- --:--:--   181
100 73750    0 73750    0     0  45436      0 --:--:--  0:00:01 --:--:--  385k
mkdir -p tmp/device-tree-xlnx-xilinx-v2016.4
tar -zxf dl/device-tree-xlnx-xilinx-v2016.4.tar.gz --strip-components=1 --directory=tmp/device-tree-xlnx-xilinx-v2016.4
make: *** No rule to make target 'fpga.zip', needed by 'build/fpga'.  Stop.

problem wish bash prompt

The current version of the bash prompt does not behave well with long lines and when browsing the history with up and down arrows.

I tried to follow the instructions from ArchWiki. It suggests to use \[\e[color\] and \[\e[m\] to start and to end coloring. It also says that "\[ and \] should wrap non-printing characters sequences to avoid wrong estimation of PS1 size which leads to display issues when navigating through history and editing the command line".

Finally, I obtained the following result that looks the same but behaves much better:

export PS1="\[\e[0;31m\]red\[\e[1;31m\]pitaya>\[\e[m\] "

Could you please update the bash prompt configuration in /etc/profile.d/profile.sh?

U-Boot patch 0004 is not properly git formatted.

I wish to apply the patches to u-boot-xlnx so that I can make changes. When I attempt to use git am to apply the patchset, git complains "patch format detection failed". Since the patch appears to be the fourth in a set of eleven, it should have the same format as the other patches in the set.

SCPI: GPIO direction options wrong, documentation of default direction wrong

1. The documentation of scpi commands lists the DIG:PIN:DIR values as "INP" and "OUTP", but the values in scpi-server/src/dpin.c are "IN" and "OUT". Consequently, setting the direction in accordance with the docs leads to errors.
2. The default direction after a reset is input, not output as is said in the documentation. Having high impedance as default is a good choice for GPIO, so the documentation should be changed.

ngx_http_rp_module set params infinite loop

In [RedPitaya/Bazaar/nginx/ngx_ext_modules/ngx_http_rp_module/src/rp_data_cmd.c:322]

j_params = params_root->child;
    while(j_params != NULL) {
        if(j_params->type != cJSON_Number)
            continue;
        j_params = j_params->next;
        rp_params_cnt++;
}

if j_params->type != cJSON_Number fails results in an infinite loop.

Setting the trigger

Hello. I have a doubt. I do not really know what is the trigger and how should I use it? I need to adquire data to a buffer and save it to a file only when the input in a channel is bigger than a specific value.

License

Can you tell me which is the type of license of this project?
And including it in the repository please.

recipe for /output/build/libdaemon-0.14/.stamp_configured failed

I followed the latest install instructions and run the complete Makefile. The build gets very very far but eventually I stumble upon this error and I am clueless how to work around it.

I made a copy of my screen for the last bit. If I can provide certain logfiles let me know.

rp_data_get_signals() in ngx_http_rp_module assumes fixed signal count and size

Hi all,
I am writing a custom web application. Changing the number and size of the signals works not as expected because the ngix module assumes fixed values:
https://github.com/RedPitaya/RedPitaya/blob/master/Bazaar/nginx/ngx_ext_modules/ngx_http_rp_module/src/rp_data_cmd.c#L413

if(rp_signals == NULL) {
int i;
rp_signals = (float **)malloc(3 * sizeof(float *));
for(i = 0; i < 3; i++) {
rp_signals[i] = (float *)malloc(2048 * sizeof(float));
}
}

Especially if you have bigger values in your app bad things might happen.

/dev/spidev1.0 not present in stock 0.95 ecosystem

.. and as a result, SPI is not functional.

missing /opt/redpitaya/hostapd.conf

Hi Iztok,

I've just had a look at the new Red Pitaya SD card image trying to understand why Wi-Fi access point does not work (there is even a forum thread dedicated to this problem).

Apparently, line 62 in debian.sh does not work and /opt/redpitaya/hostapd.conf is not copied to the SD card image.

As a workaround, I tried to download this file from GitHub with the following commands:

/opt/redpitaya/sbin/rw
curl -L https://raw.githubusercontent.com/RedPitaya/RedPitaya/master/OS/debian/overlay/etc/hostapd/hostapd.conf -o /opt/redpitaya/hostapd.conf
/opt/redpitaya/sbin/ro

After a reboot, Wi-Fi access point started to work.

Could you please fix debian.sh?

Cheers,

Pavel

ext4 filesystem on released OS image was not unmounted cleanly

After downloading and unzipping this official image from the Red Pitaya site and mounting the OS partition in the image, I noticed that the filesystem wasn't unmounted cleanly: mount wanted to repair it, which failed initially because I had mounted the image file itself read-only:

$ udisksctl loop-setup -r -f red_pitaya_OS-beta.img
Mapped file red_pitaya_OS-beta.img as /dev/loop0.
$ # can't use udisksctl to mount partition because of https://bugs.freedesktop.org/show_bug.cgi?id=98858
$ sudo mount -o ro /dev/loop0p2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0p2,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

[from dmesg]

[33824.747555] EXT4-fs (loop0p2): INFO: recovery required on readonly filesystem
[33824.747556] EXT4-fs (loop0p2): write access unavailable, cannot proceed

I've encountered this problem before with other disk images which were generated by shell scripts: the only workaround I've found which seems to mitigate this somewhat is to add one or more sync commands (perhaps interspersed with sleep 1 commands) before the final umount.

If perhaps the image was tested on a real Red Pitaya before copying the SD-card to an image file, please make sure to cleanly unmount filesystems (perhaps using systemctl halt) instead of simply pulling the plug.

Nginx Makefile missing

Reference commit : 7d0769e

I do not find the Makefile required to compile Nginx:

$(NGINX): $(URAMDISK) $(LIBREDPITAYA) $(WEBSOCKETPP_DIR) $(CRYPTOPP_DIR) $(LIBJSON_DIR) $(LUANGINX_DIR) $(NGINX_SRC_DIR) $(BOOST_DIR)
    $(MAKE) -C $(NGINX_DIR) SYSROOT=$(SYSROOT)
    $(MAKE) -C $(NGINX_DIR) install DESTDIR=$(abspath $(INSTALL_DIR))

Could you please add it to the repository ?
Thank you !

Please create a tag for version 0.93

Dear RedPitaya developers,

The version number of the SD image zip file downloadable from redpitaya.com is 0.93.

Looking at the RedPitaya github repository, it's not clear what code is used to build this SD image zip.

Could you please create a tag corresponding to this version?

Kind regards,

Pavel

AUTO button: Shows more than 1.5 periods above 250 kHz signals

Release 0.90, RM-3675

When AUTO button is pressed and signal applied to one of the input channels is above 250 kHz, more than 1.5 periods are shown on the diagram.

SCPI: documentation of burst mode settings wrong

The SCPI command documentation lists the parameter for SOUR<n>:BURS:STAT <par> as ON or OFF, but the scpi-server evaluates <par> as one of CONTINUOUS, BURST, STREAM. The corresponding query command uses the same values as returns.

problem with direct memory access in v0.97

Dear Red Pitaya developers,

I've just tested one of the recent SD card images (red_pitaya_OS-v0.97-f9094af-release.zip) and found that the direct memory access in my MCPHA application doesn't work with this SD card image. It works fine with v0.95.

My FPGA configuration is writing data to RAM via S_AXI_HP0 and a C program is reading the data starting from the address 0x1e000000.

In v0.97, some parts of the data are corrupted.

I suspect that the source of the problem is in the PCW_S_AXI_HP0_DATA_WIDTH parameter set to 32 in system.tcl:
https://github.com/RedPitaya/RedPitaya/blob/master/fpga/prj/logic_orig/ip/system.tcl#L974
https://github.com/RedPitaya/RedPitaya/blob/master/fpga/prj/logic/ip/system.tcl#L991

Similar problems were reported in the following Xilinx forum threads:
https://forums.xilinx.com/t5/Embedded-Linux/Corrupted-data-received-from-AXI-DMA-via-HP0-in-32-bit-mode/td-p/715245
https://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/AXI-DMA-IP-Issues-with-Zynq-Zedboard-Running-Linux/td-p/412683

Could you please set PCW_S_AXI_HP0_DATA_WIDTH to 64?

Best regards,

Pavel

Problem working with time

Hello. I have a problem with time. I have a problem that works for a specific time, let's call it measure_time. i did the following program:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <time.h>

int main (int argc, char **argv) {
clock_t start, end;
volatile double elapsed;
start = clock();

if(rp_AcqStart() != RP_OK)
{
   	fprintf(stderr, "\tError: Start of the Acquisition failed\n");
   	return EXIT_FAILURE;
}

usleep(135);
while(1)
{
    rp_AcqSetTriggerSrc(RP_TRIG_SRC_CHB_NE);
    rp_acq_trig_state_t state = RP_TRIG_STATE_WAITING;
    while(1)
    {	
	end = clock();
    	elapsed = ((double) (end-start)) / (double) CLOCKS_PER_SEC;
    	if(elapsed >= measure_time)
    	{
        	    goto timeover;
    	}
    	
        /*Here some processing is done*/
    }
}
timeover: 
rp_Release();
return EXIT_SUCESS
}

The program works perfect when measure_time is 4 minutes (240 seconds), however when I set it to work for 5 minutes (300 seconds) it does stop after the time has passed. I guess it has to do with the clock or something like that but I am not sure. Any explanations?

xdc on Vivado 2014.4

Need change IOSTANDARD for XADC pins to LVCMOS33 to generate bitstream using Vivado 2014.4

Ethernet connection manager

DHCP mechanism is initiated by Red Pitaya only at the end of the boot procedure, while it should be initiated at each link-up event.

Please create tags corresponding to the RedPitaya ecosystem releases

Dear RedPitaya developers,

Looking at the RedPitaya github repository, it's not clear what code corresponds to what release.

Could you please create tags corresponding to the RedPitaya ecosystem releases?

Kind regards,

Pavel

What is rp_CalibInit(); for what and when should I use it?

Hello. In rp.h I see this function here:
/**

• Initializes the library. It must be called first, before any other library method.
• @return If the function is successful, the return value is RP_OK.
• If the function is unsuccessful, the return value is any of RP_E* values that indicate an error.
  */
  int rp_Init();

int rp_CalibInit();

However it does not have a description. When should I use it?

Thanks

PID saturation

At the end of the pid_block module, the pid output is saturated with

if ({pid_sum[33-1],|pid_sum[32-2:13]} == 2'b01) //positive overflow pid_out <= 14'h1FFF ; else if ({pid_sum[33-1],&pid_sum[33-2:13]} == 2'b10) //negative overflow pid_out <= 14'h2000 ; else pid_out <= pid_sum[14-1:0] ;

shouldn't the "32-2" index in the positive read "33-2" ? Also, what is the current usage of pid_bloc.sv vs red_pitaya_pid_block.sv ?

Can't build RedPitaya

OS: Archlinux x86_64

gdate.c:2497:7: error: format not a string literal, format string not checked [-Werror=format-nonliteral]
tmplen = strftime (tmpbuf, tmpbufsize, locale_format, &tm);

in >>> host-libglib2 2.38.2 Building step

SCPI: documentation of data format parameters wrong

The documentation of scpi commands lists the ACQ:DATA:FORMAT options "ASCII" and "FLOAT", but it should be "ASCII" and "BIN". Some explanation how the data is encoded in binary mode should also be added.

LED 8 weakly lit after bootup

LED 8 is weakly lit right after boot-up. GPIO block 0 not properly initialized.
Ref. and temporary workaround here, https://redpitaya.zendesk.com/hc/communities/public/questions/200247982-LED-8-always-on-at-50-intensity

Mine is RP v1.1 eco. 0.93-14 and this issue is still present.

CLI LCR fails to find /opt/bin/monitor

The correct path appears to be /bin/redpitaya/bin/monitor.

Vivado 2014 support

ISE is discontinued after 2013. Are there any plans to make your designs compatible with Vivado 2014?

Currently, one is not able to make the project due to the following errors:

CRITICAL WARNING: [Board 49-4] Problem parsing board_part file - /opt/Xilinx/Vivado/2014.2/data/boards/board_parts/zynq/zc706/1.0/board_part.xml, The board part 'xc7z045ffg900-2' is either not supported or invalid.
CRITICAL WARNING: [Board 49-4] Problem parsing board_part file - /opt/Xilinx/Vivado/2014.2/data/boards/board_parts/zynq/zc706/0.9/board_part.xml, The board part 'xc7z045ffg900-2' is either not supported or invalid.
CRITICAL WARNING: [Board 49-4] Problem parsing board_part file - /opt/Xilinx/Vivado/2014.2/data/boards/board_parts/kintex7/kc705/1.0/board_part.xml, The board part 'xc7k325tffg900-2' is either not supported or invalid.
CRITICAL WARNING: [Board 49-4] Problem parsing board_part file - /opt/Xilinx/Vivado/2014.2/data/boards/board_parts/kintex7/kc705/0.9/board_part.xml, The board part 'xc7k325tffg900-2' is either not supported or invalid.

As well as some IP that needs to be updated from version 5.3 to version 5.4.