Electronic – SPI chip select optimisation

digital-logicoptimizationspi

I am designing an SPI system with one master and two slaves. In a normal SPI system, the master needs 2 outputs to control the slaves' chip select lines. I want to use only one output to drive both chip selects thanks to a classic NOT gate.

schematic

^{simulate this circuit – Schematic created using CircuitLab}

I haven't tried this yet because I see one issue:

When the master command comes from HIGH to LOW, both chips will be selected for a short time due to the NOT gate delay.

Can this issue cause an overall problem?

Edit:

For this easy scenario, a "not" gate does the job, what is commonly used when there are many more slaves? MUX?

Best Answer

If you really only have two devices, this can work if you're careful. Some points to consider:

Make sure to switch the slave select line only between full sequences and with some dead time before and after you try to transfer data.
Many chips use the leading edge of SS to reset their logic to the start of a new sequence. Even if you are using the same chip several sequences in a row, you will have to de-assert its SS between sequences. This means the other chip will see its SS asserted for short blips. That should be OK, but again, make sure this is only happening when the data and clock lines are quiescent.
The low level firmware may need to do a extra SS pulse to guarantee that the target device sees the leading edge of SS, not just SS asserted at the start of a sequence.

Related Solutions

Spi interrupt code

With SPI the master generates the clock so there's not really a concept of being able to receive multiple bytes back from a slave automatically, you have to send additional dummy bytes to generate the clock. Say if you had a sensor and you wanted command 0x01 to send back the current temperature the pseudo-code for the master may look like:

spi_write(0x01);
t_lsb = spi_write(0x00); // These dummy bytes are just needed to generate a clock
t_msb = spi_write(0x00); // So that the slave gets a chance to send the results back

On and the slave it might look like:

cmd = spi_read();
if (cmd == 0x01) {
  spi_write(t_lsb);
  spi_write(t_msb);
}

You can technically send back a byte from the slave for each byte sent from the master, but for most protocols there probably isn't anything useful to send back until the slave has received and decoded the command. Hopefully you can understand that pseudo-code and the general concept OK, it's been a while since I've programmed PIC SPI at the register level but it sounds like you're on top of that side of things.

Electronic – Design review: SPI, ISP and multiple slaves

First, you have identified a really annoying part of SPI on the AVR: Connecting SPI slaves will interfere with the proper operation of ICSP.

Second: The SPI bus has MISO, MOSI, and a chip select pin. You can break out the MISO, MOSI and GND pins, and perhaps VCC, plus a different CS pin for each daughter board you want to connect. As long as the CS is not active for the daughter boards, and the daughter board chips do not try to use the bus in master mode, you should be OK.

Third: You can use a buffer chip of some sort (perhaps 74HC125 or similar) with a tri-state function to isolate the ICSP feature from the SPI-talking-to-slaves feature; set the buffer chip up to require a particular pin high to let signals through, and use software to pull that pin high only when your code wants to talk to the slaves, and keep it low after a code reset.

Best Answer

Related Solutions

Spi interrupt code

Electronic – Design review: SPI, ISP and multiple slaves

Related Topic