Multi-slave SPI

Ken,

1) SPISTE - as you mention, SPISTE is used as a chip-select and is most useful in a point-to-point setup.  In many applications, I've seen customers use several individual GPIOs as individual chip selects for each slave.

---

2) Clocking - it is often true that the device's oscillator is not good enough for CAN communications by default. However, since you appear to be using SPI-CAN converters (not the CAN module itself) I would think that this would reduce the oscillator's accuracy requirements.   To be sure of this you'd need to look at the SPI specifications for the SPI-CAN converter.

Note that there are other ways of increasing the internal oscillator's accuracy and precision.  It assumes you have some spare cycles that can be spent on calibration.  In many systems this improves the oscillator to be good enough for CAN's specifications.  If interested, see the following appnote (sprabi7 and its accompanying software):
http://www.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=sprabi7a&docCategoryId=1&familyId=919

---

Thank you,
Brett

Ken,

The SPISTE output will go low a partial SPI clock cycle before the SPICLK starts and go high a partial SPI clock cycles after the SPICLK stops.  This is its definition.  It has no idea what you are actually doing with chip selects (this assumes that you've set the SPI up as a SPI master).

You can use three GPIOs and tie one GPIO output to each SPI slave.  You would then need to manage these GPIO pins yourself via software to enable the proper slave when its packet is sent.  If there are any timing requirements between when chip-select goes low and when clocks arrive (occasionally a concern) these will also need to be handled manually via software.

Finally, if you aren't using SPISTE, you can always edit the GPIOMUX so that SPISTE doesn't get output.  This will allow for more efficient usage of your GPIOs.


Thank you,
Brett