Hello all,
are the SPI-interfaces on the standard Cape design accessible in the out-of-the-box design?
I tried to use spidev from Python but even though I see spi0…3 in /sys/class/spi_master I cannot open these.
Any ideas?
Cheers
Moadl
Hello all,
are the SPI-interfaces on the standard Cape design accessible in the out-of-the-box design?
I tried to use spidev from Python but even though I see spi0…3 in /sys/class/spi_master I cannot open these.
Any ideas?
Cheers
Moadl
There is one SPI interface on P9_17/P9_18/P9_21/P9_22
For reference, the default cape gateware IO list can be found here: sources/FPGA-design/script_support/components/CAPE/DEFAULT/Readme.md · main · BeagleV-Fire / Gateware · GitLab
Hi @Vauban,
yes, the SPI-interface is there, however how would i access that from the MSS and its Linux-system?
My issue is that I was trying via Python and the spidev package (spidev · PyPI) which would open SPIs which are located in /dev/spidev.. The Beagle-board has them in /sys/class/spi_master and hence nothing is found when trying to open the interface.
Would there be any reference-example already available that shows how to access the SPI on the on-board ADC? That would be my target to read out.
Cheers
Moadl
Sorry, I do not have a board at hand right now. Could you take a look in /usr/share/microchip on the board? Is there a python script there that exercises the on-board ADC?
Hi @Vauban,
thanks for the pointer, that was the correct place. There is a python-script that reads the ADC and shows how to handle the IF.
Cheers
Moadl
Hi @moadl,
How did you get SPI to work?
Hi @turaib
I went to the directory that Vauban had mentioned (/usr/share/microchip/gateware).
This directory contains a python-script called “mcp356x_read.py” which accesses the on-board ADC via SPI and then prints the read values via lots of puts-commands.
Cheers
Moadl
Hello!
My colleague Csaba H. managed to make SPI available from user space as spidev. Here is a detailed description of it: https://gist.github.com/cshegedus-dsp/e6346426278f7e1aeba785cb6d337dbf
I can see data traffic on SPI0.SDO, but SPI0.CS0 doesn’t want to move for some reason. At one point, not long ago, it did work, and I didn’t need a cs-gpios line. I’m confounded as to why it stopped working, and how I can get it back. The following device tree entry gets SPI data traffic, but no Chip select… likely because P9_17 is not defined anywhere I can find:
&spi0 { status = “okay”; cs-gpios = <&cape_gpios_p9 6 0>; // How do I get P9_17 here? #address-cell = <1>; #size-cells= <0>; spidev0: spidev@0 { compatible = "rohm,dh2228fv"; reg = <0>; symlink = "bone/spi/0.0"; spi-max-frequency = <1000000>; };};
What do I need to do to get the chip select functioning correctly?
Terrible habit, resurrecting old threads like this…
That being said, you know you can move about your tree with git checkout <sha>, right?
Once you have your “known good”, you can bisect from there to narrow down the culprit.
Yeah, or someone could post an actual answer to the original post, like this:
&spi0 {
status = “okay”;
spidev0: spidev@0 {
compatible = “rohm,dh2228fv”;
reg = <0>;
symlink = “bone/spi/0.0”;
spi-max-frequency = <1000000>;
};
};
In the device tree for the default cape works if you have spi-tools installed.
Kazzam. I am off to look up spi-tools.
True. Had someone actually done that a year ago.
However, your post wasn’t an answer, it was another question,
so not only was it necroing, but also hijacking.
Furthermore, I really don’t see how spi-tools becomes a prerequisite
for making SPI work, but I’m always happy to learn something new…
Granted, it makes testing from the command-line easier to do,
but that’s not how I read your statement.
Now, don’t get me wrong, we do encourage people to be inquisitive and ask questions,
but there’s a right way and a wrong way to do it; yours is obviously wrong.
If you have a valid question, and you clearly have, make a new thread for it.
That’s the right way.