Skip to main content
added 7 characters in body
Source Link
Maple
  • 13.1k
  • 2
  • 26
  • 63

Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.

UPDATE:

I was digging around for other stuff and found this chip that I think fits perfectly into your application. ADG731 is 32 channel SPI controlled multiplexer/demultiplexer. So, you can put it on the same SPI channel as your slaves to switch CS line between them (the mux CS will be separate, of course).

This would work even better than switching CS with shift registers as I suggested above, since
a) you would not be activating slaves right away while switching,
b) you can target any slave in any order, and
c) you will free 2 of the I/O lines used to control shift registers

Add tiny dual buffer for SCK and MOSI and you have faster directly-addressable 2-chip solution instead of 27 chips with address shifting.

Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.

UPDATE:

I was digging around for other stuff and found this chip that I think fits perfectly into your application. ADG731 is 32 channel SPI controlled multiplexer/demultiplexer. So, you can put it on the same SPI channel as your slaves to switch CS line between them (the mux CS will be separate, of course).

This would work even better than switching CS with shift registers as I suggested above, since
a) you would not be activating slaves right away while switching,
b) you can target any slave in any order, and
c) you will free 2 I/O lines used to control shift registers

Add tiny dual buffer for SCK and MOSI and you have faster directly-addressable 2-chip solution instead of 27 chips with address shifting.

Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.

UPDATE:

I was digging around for other stuff and found this chip that I think fits perfectly into your application. ADG731 is 32 channel SPI controlled multiplexer/demultiplexer. So, you can put it on the same SPI channel as your slaves to switch CS line between them (the mux CS will be separate, of course).

This would work even better than switching CS with shift registers as I suggested above, since
a) you would not be activating slaves right away while switching,
b) you can target any slave in any order, and
c) you will free 2 of the I/O lines used to control shift registers

Add tiny dual buffer for SCK and MOSI and you have faster directly-addressable 2-chip solution instead of 27 chips with address shifting.

added 718 characters in body
Source Link
Maple
  • 13.1k
  • 2
  • 26
  • 63

Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.

UPDATE:

I was digging around for other stuff and found this chip that I think fits perfectly into your application. ADG731 is 32 channel SPI controlled multiplexer/demultiplexer. So, you can put it on the same SPI channel as your slaves to switch CS line between them (the mux CS will be separate, of course).

This would work even better than switching CS with shift registers as I suggested above, since a
a) you would not be activating slaves right away while shifting and bswitching,
b) you can target any slave in any order., and
c) you will free 2 I/O lines used to control shift registers

Add tiny dual buffer for SCK and MOSI and you have faster directly-addressable 2-chip solution instead of 27 chips with address shifting.

Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.

UPDATE:

I was digging around for other stuff and found this chip that I think fits perfectly into your application. ADG731 is 32 channel SPI controlled multiplexer/demultiplexer. So, you can put it on the same SPI channel as your slaves to switch CS line between them.

This would work even better than switching CS with shift registers as I suggested above, since a) you would not be activating slaves right away while shifting and b) you can target any slave in any order. Add tiny dual buffer for SCK and MOSI and you have faster directly-addressable 2-chip solution instead of 27 chips with address shifting.

Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.

UPDATE:

I was digging around for other stuff and found this chip that I think fits perfectly into your application. ADG731 is 32 channel SPI controlled multiplexer/demultiplexer. So, you can put it on the same SPI channel as your slaves to switch CS line between them (the mux CS will be separate, of course).

This would work even better than switching CS with shift registers as I suggested above, since
a) you would not be activating slaves right away while switching,
b) you can target any slave in any order, and
c) you will free 2 I/O lines used to control shift registers

Add tiny dual buffer for SCK and MOSI and you have faster directly-addressable 2-chip solution instead of 27 chips with address shifting.

added 718 characters in body
Source Link
Maple
  • 13.1k
  • 2
  • 26
  • 63

Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.

UPDATE:

I was digging around for other stuff and found this chip that I think fits perfectly into your application. ADG731 is 32 channel SPI controlled multiplexer/demultiplexer. So, you can put it on the same SPI channel as your slaves to switch CS line between them.

This would work even better than switching CS with shift registers as I suggested above, since a) you would not be activating slaves right away while shifting and b) you can target any slave in any order. Add tiny dual buffer for SCK and MOSI and you have faster directly-addressable 2-chip solution instead of 27 chips with address shifting.

Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.

Why would you "isolate the other SPI slaves when connected to one"? The whole point of using SPI is that CS line activates only one slave at a time.

Is it to deal with fan-out load on SCK and MOSI lines? A simple buffer driving signal "bus" would be sufficient for this.

Or is it to multiplex SCK signal as well? I don't think you need to do this. Instead of using shift registers to multiplex signals, you can use them to directly drive CS pins of the slaves. If your software does not output clock signal until correct slave selected there is absolutely no harm in "activating" them one by one without actual transmission.

I think the limiting factor in your design is line capacitance, which will grow regardless of what you connect to RPi outputs, buffers or slaves.

So, use shift registers to activate CS pins on slaves and use simple line buffers on SCK and MOSI.

UPDATE:

I was digging around for other stuff and found this chip that I think fits perfectly into your application. ADG731 is 32 channel SPI controlled multiplexer/demultiplexer. So, you can put it on the same SPI channel as your slaves to switch CS line between them.

This would work even better than switching CS with shift registers as I suggested above, since a) you would not be activating slaves right away while shifting and b) you can target any slave in any order. Add tiny dual buffer for SCK and MOSI and you have faster directly-addressable 2-chip solution instead of 27 chips with address shifting.

Source Link
Maple
  • 13.1k
  • 2
  • 26
  • 63
Loading