SPI Chip Select for different slaves

Question

1)I need to design hardware for SPI communication with 2 different slaves. Slaves chip select pin is being pulled from high to low by the GPIO pin(port output)of the Master. But on the hardware design, I have only one port pin left. Can the same port pin be used to enable/disable the chip select pin of both the slaves? Response from both slave are obtained at different timing. Both slaves are not identical. Clock for both the slaves are derived from the system clock.The connection is as shown below (Fig1). Can this design possible for SPI communication? Also can anyone tell which design (shown below) is recommended. Fig 2 or Fig3 Is it necessary that different slave should have its own SPI unit?
2) Which factor decide if daisy chain type SPI communication possible or not? Because in datasheet of both slaves it specifies, daisy chain type SPI communication is not supported. Does slave decides about the possibility of daisy chain type SPI communication?Can someone please explain how daisy chain communication happens?

Thanks

Answer 1

The usual arrangement is to share MOSI and MISO between the slaves, and have a separate CS for each slave.

^{simulate this circuit – Schematic created using CircuitLab}

This works if, like most SPI devices, your slaves are designed to not respond to inputs or drive their MISO outputs when CS is not asserted.

If Fig 1 is your current set-up, changing to this arrangement would actually free up GPIO lines.

Answer 2

1) Put a not-gate built with a transistor (output taken from collector) driven from remaining port pin. Use output of this gate for one CS and use port output for the other one.

Note that you won't be able to de-select both chips. Which means, if you un-select one then the other will be selected.

Answer 3

You could use a single I/O pin to drive two chip selects, routing the I/O pin level directly to /CS1 and through an inverter to /CS2. It means that one device is always selected and it depends upon the SPI devices you have as to whether they'll like that. Some SPI devices communicate commands/data when /CS is asserted then action those commands/data when /CS is negated. You'll have to assess the devices you have yourself. Generally, avoid it if at all possible, it complicates your software.

The benefit of each SPI device on its own SPI master versus a shared SPI bus depends on the application.

You'd favour a shared SPI bus when you only have one master or when the PCB is very dense and you want to route fewer tracks.

You'd favour an SPI master per SPI device when the bus is going to a PCB connector, causing a long bus length that also could could be shorted off-PCB and kill the whole bus. Or when your SPI devices need fast transfers or transfers at precisely-timed intervals which stop you just alternating between devices.