Three (3x) SPI devices on Pmod HAT Adapter? (stacking/direct GPIO etc)

[Renier]

I desperately want to connect  three devices to a Raspberry Pi3 that has a single Pmod HAT Adapter fitted to it.

The devices are all SPI types:

• Pmod AD1
• Pmod ISNS20
• Pmod TC1

I can only run 2x devices since ports JA(A) and JB(A) both support SPI, but JC(A) does not.

Is stacking of Pmod HAT Adapters allowed or can I connect an SPI device directly to the open GPIO pins?

I would greatly appreciate any advice! Even if NOPE is an answer...

 

[xc6lx45]

If "desperate", I guess you can do SPI by bit-banging GPIOs (haven't checked the schematic). Most likely there is a more elegant solution, though.

If write-only, I think the Pi's SPI interface does not manage the CS pins, it's up to the user. So I could connect any number of write-only devices to one port.

Cascading devices might be another option (device output A becomes device B input, it's just shift registers), but no idea how this would look in existing SW libraries. I've used it once on a "B" to talk to an FPGA - managed 60 MHz, by the way - but it's a while ago.

[xc6lx45]

BTW, this is probably borderline OT. But a USD 6 Dupont crimp tool from Ebay can be my best friend when I have to build a prototype "backplane" for 1/10 in modules:

[Renier]

9 minutes ago, xc6lx45 said:

If "desperate", I guess you can do SPI by bit-banging GPIOs (haven't checked the schematic). Most likely there is a more elegant solution, though.

If write-only, I think the Pi's SPI interface does not manage the CS pins, it's up to the user. So I could connect any number of write-only devices to one port.

Cascading devices might be another option (device output A becomes device B input, it's just shift registers), but no idea how this would look in existing SW libraries. I've used it once on a "B" to talk to an FPGA - managed 60 MHz, by the way - but it's a while ago.

Thanx for the response! At my current "NEWBIE" level: If I cant plug it in somewhere and use Python to read them, its gonna get REALLY interesting.

Main aim was just to have a single point to collect data and keep the costs and complexity down.

R

[xc6lx45]

OK it's all sensors...

I'd look at the thermocoupler data sheet and build a simple bitstream to read the temperature via GPIOs.

In pseudocode this would be
 

string clck= "010101010101010101..."
string data= "001100000000110011... your SPI bitstream here"
string read= "0000000x0x0x0x0x0x ..." the interesting bits

long val = 0;
CS_GPO = 0; (active)
for (int ix = 0; ix < length(clck); ++ix){
  CLK_GPO = clkk[ix];
  MOSI_GPO = data[ix];
  if (read[ix] == "x"){
	  val |= (MISO_GPI);
	  val <<= 1;
   }
}
CS_GPO = 1;

... do something with val.
The exact SPI timing (when to raise the clock and when to sample the output value) is usually described in the data sheet.

Also the bit order for val needs to come from the data sheet.

But, maybe someone more familiar with the ecosystem comes up with a nicer solution.

[Renier]

2 minutes ago, xc6lx45 said:

OK it's all sensors...

I'd look at the thermocoupler data sheet and build a simple bitstream to read the temperature via GPIOs.

In pseudocode this would be
 

string clck= "010101010101010101..."
string data= "001100000000110011... your SPI bitstream here"
string read= "0000000x0x0x0x0x0x ..." the interesting bits

long val = 0;
CS_GPO = 0; (active)
for (int ix = 0; ix < length(clck); ++ix){
  CLK_GPO = clkk[ix];
  MOSI_GPO = data[ix];
  if (read[ix] == "x"){
	  val |= (MISO_GPI);
	  val <<= 1;
   }
}
CS_GPO = 1;

... do something with val.
The exact SPI timing (when to raise the clock and when to sample the output value) is usually described in the data sheet.

Also the bit order for val needs to come from the data sheet.

But, maybe someone more familiar with the ecosystem comes up with a nicer solution.

Thanx for the effort!!!

I really appreciate it!

Lets see how far I can go without making smoke

R

[JColvin]

Hi @Renier
 

And to answer the question about stacking Pmod HAT adapters on top of each other, while the boards are all pin compatible so you would not cause an immediate short circuit or anything like that, because the pins are all routed to the same location, there would be no way for the boards or the Raspberry Pi to differentiate between JA on one HAT adapter vs a different HAT adapter, so it would not work in that fashion.

Otherwise @xc6lx45's suggestions of bitbanging the SPI protocol will be one solution.

Alternatively, you can take advantage of the fact the SPI protocol selects which slave device it is talking to based on the chip select pin. With this, you could set it up so that the third Pmod is connected to the same physical clock and data lines (MOSI, MISO, SCLK) as the Pmod on JA or JB via a wire splitter (not a technical term) of some kind. You could then manually pull the chip select line low in your code and then use the built in SPI wiring to send all of the data. The catch here will be if the SPI code for the Raspberry Pi does not let you specify/customize which chip select pin you are using so you end up talking to another SPI Pmod at the same time, which can cause issues. You will also need to make sure (if the previous thing is not an issue) is that you then do not have the Raspberry Pi communicate with the two Pmods connected to the same SPI port at the same time. It won't look as pretty visually as just plugging the Pmod into JC, but something to consider.

Thanks,
JColvin

[jpeyron]

Hi @Renier,

I am not sure with the Raspberry Pi but on a microcontroller i was able to use multiple spi devices off of the port used for SPI1. I did not connect the CS on SPI1 port but rather used standard GPIO pins on another port for the CS of the different SPI devices.  

cheers,

Jon

[Renier]

11 hours ago, JColvin said:

Hi @Renier
 

And to answer the question about stacking Pmod HAT adapters on top of each other, while the boards are all pin compatible so you would not cause an immediate short circuit or anything like that, because the pins are all routed to the same location, there would be no way for the boards or the Raspberry Pi to differentiate between JA on one HAT adapter vs a different HAT adapter, so it would not work in that fashion.

Otherwise @xc6lx45's suggestions of bitbanging the SPI protocol will be one solution.

Alternatively, you can take advantage of the fact the SPI protocol selects which slave device it is talking to based on the chip select pin. With this, you could set it up so that the third Pmod is connected to the same physical clock and data lines (MOSI, MISO, SCLK) as the Pmod on JA or JB via a wire splitter (not a technical term) of some kind. You could then manually pull the chip select line low in your code and then use the built in SPI wiring to send all of the data. The catch here will be if the SPI code for the Raspberry Pi does not let you specify/customize which chip select pin you are using so you end up talking to another SPI Pmod at the same time, which can cause issues. You will also need to make sure (if the previous thing is not an issue) is that you then do not have the Raspberry Pi communicate with the two Pmods connected to the same SPI port at the same time. It won't look as pretty visually as just plugging the Pmod into JC, but something to consider.

Thanks,
JColvin

JColvin

 

Thanx for the assistance. I will now have to play around abit. Many thanx!

R

[Renier]

10 hours ago, jpeyron said:

Hi @Renier,

I am not sure with the Raspberry Pi but on a microcontroller i was able to use multiple spi devices off of the port used for SPI1. I did not connect the CS on SPI1 port but rather used standard GPIO pins on another port for the CS of the different SPI devices.  

cheers,

Jon

jpeyron

 

Many thanx for the assistance. I will try these suggestion.

R

[xc6lx45]

Writing to multiple parallel devices on one port should be easy by using multiple CS signals, but those three modules are all sensors. What would I do with the MISO pins?

[JColvin]

Hi @xc6lx45,

They would end up being "wire-split" among the three sensors as well, though you would have to ensure that none of the sensors are being communicated to/with at the same time, otherwise you will end up getting the SPI equivalent of a bus collision (though I don't know if that is formally defined in the SPI protocol). Depending on the application though, if you are okay only getting data from each sensor about once a second (I haven't checked, but I think that is enough time for all of the acquisition and conversion phases), it hopefully won't be a huge detriment. Just my thoughts though.

[sry2]

I have the same problem I was looking to use Pmod for motor current (iSNS20), pressure transmitter (AD1) and k type thermocouple (TC1).

I found a work around by arranging to get the temperature sensor connected in a different way as follows

1) 1-wire system using DS18B20 digital temperature sensors using a single spare HAT GPIO pin (I used GPIO25). I set it up using 3 sensor in series

https://www.raspberrypi-spy.co.uk/2013/03/raspberry-pi-1-wire-digital-thermometer-sensor/

2) Using an Adafruit K type thermocouple break out board MAX31855 and the Adafruit python library. You can set up a software SPI bus using more of the spare HAT ports, 3.3V power and Gnd

I used

GPIO22  to CLK

GPIO23  to CS

GPIO24  to DO 

https://learn.adafruit.com/max31855-thermocouple-python-library

 

I now have 3 DS18B20 sensors (up to 120 degC) and one K type thermocouple and it works Ok