SPI2 on RPI connector of mangOH is connected to embedded WiFi/BT chipset (MT7697) via USB-to-SPI adapter (CP2130).
MT7697 is using CS0 chipselect from CP2130, but other chipselect signals (CS1 and CS2) are theoretically available to connect other slave devices.
As CP2130 driver is not pre-integrated into Linux system then I would encourage you to use the native SPI1 interface of WP7702 module which is available on IOT0 connector.
@dfrey, In my setup, IoT slot is occupied. So, I have to use RPI connector to interface other device. @jay’s response says that SPI on RPi connector used by mt7697. Will there be any conflict with WiFi functionality, if connected to any other device?
Another thing is the procedure for enabling spidev2.
Can we use SPI on RPi along with WiFi and IoT functionality?
If yes, please guide me through the procedure.
If no, please suggest if any alternatives.
The USB bus of the WP module has a cp2130 USB to SPI adapter chip on it. That chip has a number of different chip selects. CS0 of that chip is connected to the mt7697. CS1 and CS2 go to the RPI connector. The process of using the cp2130. So yes, it should be possible to interact with the MAX6675 breakout board using the CP2130 SPI interface in combination with CS1 or CS2 on the RPI connector.
I did a quick search and I found that the MAX6675 is supported by a mainline Linux kernel driver: https://github.com/torvalds/linux/blob/master/drivers/iio/temperature/maxim_thermocouple.c
Unfortunately, this driver doesn’t exist in the WP77 kernel, but it could be backported and then built and loaded by Legato similar to the bmi160 driver. One odd thing about the cp2130 driver is that you have to write to a sysfs file to bind a driver to a chip select and setup the properties of the device. I dug this snippet out of an old e-mail: echo -n 0,2,6,0,0,1,0,0,0,0,0,mt7697 > /sys/devices/platform/msm_hsic_host/usb1/1-1/1-1.3/1-1.3:1.0/channel_config
You would replace “mt7697” with “max6675” in your case. You would likely have to update a number of the other fields as well. You have to look at the cp2130 driver to understand what the numbers mean.
The command I posted was intended as more of an example than an exact solution. On the wp85 that I’m working on right now, the path is /sys/devices/platform/msm_hsic_host/usb1/1-1/1-1.1/1-1.1:1.0/channel_config. I’m not sure if the location will be exactly the same on a wp76, but you could just do find /sys -name 'channel_config'. Also, the string being written to the file will definitely have to change. It affects the speed, chip select, driver and a bunch of other stuff. See the cp2130 driver source code for an explanation.
I was going through @dfrey comments from another post SPI access on Raspberry Pi Connector. Probably intended for WP85. But, one thing - I am also using spiService to get the app talking to the SPI interface. So,
Will @dfrey’s comments (on the other blog post) hold good for me as well?
How will I reference the SPIdevice from the app? spidev1.1 (if chip select CS1 used)? If so, how to get this one instantiated from spiService? Does spiService need a rebuild with some modifications?
Thank you @dfrey and @Jay. It’s almost done.
Your suggestions helped to get SPI on RasPi connector function as required.
I was able to trace the clock and CS signal on the oscilloscope.
The loopback test is successful
I thought it’s all done. But, it is not getting the value from MAX6675 (reading zero always).
As I said, max6675 is working fine on RasPI board. I tried comparing the SPI clock/CS on mangOH and Raspberry PI. The only difference I could find is the length of the CS LOW signal. It’s a bit lengthy on mangOH (~3 times that of RaspPi). However, I don’t see this as an issue, because the data transfer will happen only when CS is LOW (both devices shows 16 clocks for SCLK). I understand they may have different hardware and drivers. But it’s a check to compare.
Please suggest if any other troubleshooting tips and steps to root-cause the issue.
Thank you for the support and guidenace.
As long as the CS does transition from high to low before the clock starts and low to high after the clock finishes, then it shouldn’t matter if there is a bit of extra idle time. From your trace image, it’s not clear whether the CS is actually changing though.
As for why the MAX6675 isn’t working… I’m not sure. Maybe check if there are minimum/maximum clock speeds and check the required polarity and phase settings.
Need a quick help on initiating the SPI bus on RPi connector.
I was thinking to keep a script file in the init.d.
Would it work?
If it works, will there be any dependency of any driver loading or something?
Idea is before the application starts, i would like to enable the SPI bus and also start the spiService, so that application can go ahead.
Thanks for the suggestion and it is inline with what I tried.
I did develop a Leato App to initiate some of the dependencies of our application. One of them is running the spidev32766.1 initialization command as given by @dfrey.
Initially, I tried keeping all the commands in a shell script. However, as it was lacking control on the results/returns, I made them as individual commands and executing from the Legato app. This app runs only once on a reboot.
The steps around this are as below…
execute the command for spi32766.1 (channel_config setup)
Start the spiService
Check for the spi devices (/dev/spi*). Here I expect 2 devices (/dev/spidev.0 and /dev/spidev32766.1)
But for me, at this moment, spiService is failing because it’s not able to create /dev/spidev.0
So, restart the spiService and check again. (Steps 3 and 5 are executed for 5 times before the result is achieved). Mostly for the second or third time, the result is achieved.
Not sure why spiService is failing for the first executed though. (the error is - Failed to set the permissions for spidev.0, as the device is not created).
Though this is not a robust solution, it is working most of the times.
One question is - when a client application fails/terminates, the service also terminates.
Is this by design? How can this be controlled i.e. not to terminate the service?
Idea is to set a fault action to the client application to restart. In this case, the client fails because Service is not running.
Let me know if any suggestions.
@asyal & @Bobby, this is one of the items on the Auto Start Issues that we are trying along with WiFi Configuration at Boot time.