Redpitaya Forum

I would like to use the SPI as well. My first RedPitaya daughterboard works well and now it would be great to add a transfer of the entire acquire buffer using SPI to a Raspberry Pi 2 for processing. A tutorial (or a push in the right direction) would be nice. The idea is that Red Pitaya is the master and Raspberry Pi 2 the slave.

--
Karri

OK, a short recap of how to get usermode access to the SPI signals on the expansion connector E2:

At the end of this little exercise you will have a device "/dev/spidev2.0" that you can open(), read() and write(). Calling these functions will result in data being written to / read from an SPI slave connected to the SPI signals on E2.

Prerequisite: you must be able to successfully build the Red Pitaya ecosystem from source. There's a ton of info in the wiki and around this forum on how to set up a suitable build environment, so I won't go into it here.

1. Do a fresh checkout of the Red Pitaya sources. Henceforth all paths are relative to the Red Pitaya source's root folder.
2. Enable the generic spidev driver in the kernel config: edit the file OS/linux/config/rp_defconfig , search for "CONFIG_SPI_SPIDEV" and change the line to "CONFIG_SPI_SPIDEV=y".
3. Delete the file FPGA/patches/bsp/devicetree_vivado_patch.patch . This patch patches another patch that we need to modify and thus gets in our way.
4. Replace the file FPGA/release1/fpga/image/src/device_tree_vivado.patch with the one in this zip. It adds the spidev device to the devicetree source and also has the changes from the previously deleted patch incorporated.
5. Build the ecosystem and write it to your SD card. When you boot the Red Pitaya with the new kernel, you should find the device spidev2.0 in the /dev folder.
6. That's it. Now write an application that opens the device and communicates with it!

@nils thanks for the recap!

Regarding the code, there is a good example on the redpitaya.com site that should work. The devicepath must be changed though.

Since I compiled my own binaries, the Xilinx first stage bootloader fires every time I boot, I don't think that's necessary, is it? If not, what coul i've done that it suddenly appeared?

noah wrote:Regarding the code, there is a good example on the redpitaya.com site that should work. The devicepath must be changed though.

Oh, I hadn't noticed that example. Thanks for pointing it out, it is indeed an excellent starting point for using the generic SPI device.

Since I compiled my own binaries, the Xilinx first stage bootloader fires every time I boot, I don't think that's necessary, is it? If not, what coul i've done that it suddenly appeared?

I don't understand what you mean by "fires every time I boot". The first stage boot loader is always the first thing to be loaded after a reset / power-up.

The first stage boot loader is always the first thing to be loaded after a reset / power-up.

That makes sense of course. BUT if i boot with the current sd card image available on redpitaya.com (0.92-65-35575ed), it starts directly with the uboot loader and the FPGA is at this point already configured, while in my build, the FPGA is not configured until this Xilinx bootloader has finished (~15sec).

But that's a bit off topic and nevermind, it's working

Thank you!

You make life so much easier for me.

--
Karri

Hi Nils,
today I build successfully the ecosystem with enabled SPI based on your perfect guide :

Nils Roos wrote:OK, a short recap of how to get usermode access to the SPI signals on the expansion connector E2:

At the end of this little exercise you will have a device "/dev/spidev2.0" that you can open(), read() and write(). Calling these functions will result in data being written to / read from an SPI slave connected to the SPI signals on E2.

Prerequisite: you must be able to successfully build the Red Pitaya ecosystem from source. There's a ton of info in the wiki and around this forum on how to set up a suitable build environment, so I won't go into it here.

1. Do a fresh checkout of the Red Pitaya sources. Henceforth all paths are relative to the Red Pitaya source's root folder.
2. Enable the generic spidev driver in the kernel config: edit the file OS/linux/config/rp_defconfig , search for "CONFIG_SPI_SPIDEV" and change the line to "CONFIG_SPI_SPIDEV=y".
3. Delete the file FPGA/patches/bsp/devicetree_vivado_patch.patch . This patch patches another patch that we need to modify and thus gets in our way.
4. Replace the file FPGA/release1/fpga/image/src/device_tree_vivado.patch with the one in this zip. It adds the spidev device to the devicetree source and also has the changes from the previously deleted patch incorporated.
5. Build the ecosystem and write it to your SD card. When you boot the Red Pitaya with the new kernel, you should find the device spidev2.0 in the /dev folder.
6. That's it. Now write an application that opens the device and communicates with it!

Every thing works (tested with "cat /dev/spidev2.0" and oscilloscope )I just have some questions about building.
- I noticed that folder "FPGA/patches/bsp" is not already there so I ignored point 2 from your guide.
Is it ok or this patch is somewhere else?
- I replaced FPGA/release1/fpga/image/src/device_tree_vivado.patch with one that you gave.
- in the end of the building i got an error that folder "shared/curl" can't be entered, I checked and saw that "curl" was not created. So I just copied "curl-7.35.0" and rename it to "curl". I am sure that this is stupid but somehow worked. Can you give me some highlight about this (still new in linux story). What was the proper way to deal, may be "device_tree_vivado.patch" has to be changed ?

I noticed that folder "FPGA/patches/bsp" is not already there so I ignored point 2 from your guide.
Is it ok or this patch is somewhere else?

After some searching I remembered that I put the offending patch there myself for some reason or other. It's not in the original codebase, so you were totally right to ignore the point.

So I just copied "curl-7.35.0" and rename it to "curl". I am sure that this is stupid but somehow worked.

The original Makefiles create a symbolic link (shared/curl -> curl-7.35.0), so you were not far from the "official" solution at all.