Access to SPI interface from Linux
-
- Posts: 24
- Joined: Mon Dec 29, 2014 7:09 am
Re: Access to SPI interface from Linux
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
--
Karri
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: Access to SPI interface from Linux
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.
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.
- Do a fresh checkout of the Red Pitaya sources. Henceforth all paths are relative to the Red Pitaya source's root folder.
- 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".
- 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.
- 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.
- 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.
- That's it. Now write an application that opens the device and communicates with it!
-
- Posts: 33
- Joined: Fri Jan 23, 2015 9:53 am
- Location: Zurich
Re: Access to SPI interface from Linux
@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?
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?
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: Access to SPI interface from Linux
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.noah wrote:Regarding the code, there is a good example on the redpitaya.com site that should work. The devicepath must be changed though.
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.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?
-
- Posts: 33
- Joined: Fri Jan 23, 2015 9:53 am
- Location: Zurich
Re: Access to SPI interface from Linux
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).The first stage boot loader is always the first thing to be loaded after a reset / power-up.
But that's a bit off topic and nevermind, it's working
-
- Posts: 24
- Joined: Mon Dec 29, 2014 7:09 am
Re: Access to SPI interface from Linux
Thank you!
You make life so much easier for me.
--
Karri
You make life so much easier for me.
--
Karri
-
- Posts: 7
- Joined: Tue May 05, 2015 8:29 pm
- Location: Ilmenau Germany
Re: Access to SPI interface from Linux
Hi Nils,
today I build successfully the ecosystem with enabled SPI based on your perfect guide :
- 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 ?
today I build successfully the ecosystem with enabled SPI based on your perfect guide :
Every thing works (tested with "cat /dev/spidev2.0" and oscilloscope )I just have some questions about building.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.
- Do a fresh checkout of the Red Pitaya sources. Henceforth all paths are relative to the Red Pitaya source's root folder.
- 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".
- 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.
- 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.
- 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.
- That's it. Now write an application that opens the device and communicates with it!
- 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 ?
-
- Posts: 1441
- Joined: Sat Jun 07, 2014 12:49 pm
- Location: Königswinter
Re: Access to SPI interface from Linux
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.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?
The original Makefiles create a symbolic link (shared/curl -> curl-7.35.0), so you were not far from the "official" solution at all.So I just copied "curl-7.35.0" and rename it to "curl". I am sure that this is stupid but somehow worked.
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 3 guests