• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 3969 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SSI(SPI) - Multiple Slaves: proper control of additional FSS lines

Bruno Saraiva
Guru 13040 points

Gentlemen,

While the question itself is not new, I was not able to find the answer for one specific detail: how to take advantage of the SSI hardware do his automatic job properly, EXCEPT for the enabling of FSS pin when using multiple slaves on the same SPI port.

General description: using 4 identical sensors, all SPI legacy. Protocol and data rate for all is obviously the same.

SSI0CLK connected to SENSOR_ALL_SPI_CLK
SSI0XDAT0 into SENSOR_ALL_SPI_MOSI
SSI0XDAT1 into SENSOR_ALL_SPI_MISO

SSI0FSS into SENSOR1_SPI_CS
GPIO_PB0 into SENSOR2_SPI_CS
GPIO_PB1 into SENSOR3_SPI_CS
GPIO_PB2 into SENSOR4_SPI_CS

If I were to use a single slave, the mere fact of adding data to the FIFO (after proper SSI configuration), would generate the correct FSS sequence, clock, and data transmission. For using the other slaves, it is necessary to manually control the FSS bit for the desired sensor, and let the SSI hardware take care of the rest. Questions...

1) If I simply change the mux settings for that port's SSI0FSS, defining it as GPIO, will it get properly disconnected from the SSI hardware control? Or will the hardware SSI still be messing up with my SSI0FSS output?

2) This particular sensor uses 32 bit words (it does not expect any shifting on FSS before 32 bits are transported). Is my understanding correct that, even if I were using a single sensor, I would still need to control FSS manually, as the hardware can automatically control it only from 4  to 16 bits?

Regards,

Bruno

  • 0
    TI__Guru**** 244400 points
    Hello Bruno,

    #1. Yes. If the SSI0FSS pin is not configured then the SSI shall not control the FSS pin. The CPU must control the GPIO for CS selection
    #2. Yes. You would need to control the GPIO for correct word size.
  • 0 in reply to Amit Ashara
    Guru 13040 points
    Thanks Amit! Back to finishing the schematics then.
  • 0 in reply to Bruno Saraiva
    Guru 27665 points

    Since you are starting design a tip for using multiple SPI chip selects.

    If you are using more than 2 chip selects then take a look at using x to y decoders for chips selects. a 2 to 4 decoder will give you 3 chip selects and an empty default slot (or 4 chip selects) from 2 output pins and a 3 to 8 decode (the good old standard '138) will give you 7 (or 8) chip selects from 3 outputs. Even if you only use 3 chip selects the '138 may make sense since it allows expanding the SPI bus in the future w/o needing to get more precious CPU pins.

    Also keep in mind that many SPI peripherals will daisy chain.

    Robert

  • 0 in reply to Robert Adsett
    Guru 13040 points
    Robert,
    Thank you for this additional suggestion. It does indeed make a lot of sense!
    Had it not been the case that this specific sensor has a 32bit word, I would revert to your suggestion - or any other logic gate that would receive the CS from the MCU and send it to the proper destination, allowing the SSI hardware to always do its magic seamlessly.
    Given that I will still need to control CS by software due to the size of the data, I'll hook one GPIO into each pin on this project...
    And no, this SPI folk does not daisy chain - but again, important reminder from your end!
    Bruno
  • 0 in reply to Bruno Saraiva
    Guru 27665 points

    Bruno Saraiva said:
    Had it not been the case that this specific sensor has a 32bit word, I would revert to your suggestion

    I don't see that it makes a difference. There's no reason to use the frame select output with the '138. I don't think the frame select is really compatible with multiple output selects in any case. Actually I'd suggest never using the frame select, it's not well implemented, there are too many ways for it to fail.

    Robert

  • 0 in reply to Robert Adsett
    Guru 13040 points

    Robert,

    Let me go back one step: one you suggested the 138, I then thought of a 1:4 Demux.

    Using something like the CD4052BPWR would be quite nice (and 4053 for those needing up to 8 slaves): you can still use the automatic FSS control from the MCU's hardware, and by means of the logic GPIO's, define "who you're talking to". This is probably an advantage on the software point of view, as the communication part is not conditional to which sensor you are targeting (or at least more elegant).

    But... if "there are many ways for the FSS to fail", and if you say it's not well implemented, one more reason I'll stick to the GPIO selecting!

    Cheers.

  • 0 in reply to Bruno Saraiva
    Guru 27665 points

    Bruno Saraiva said:
    Using something like the CD4052BPWR would be quite nice (and 4053 for those needing up to 8 slaves): you can still use the automatic FSS control from the MCU's hardware, and by means of the logic GPIO's, define "who you're talking to". This is probably an advantage on the software point of view, as the communication part is not conditional to which sensor you are targeting (or at least more elegant).

    You could do that with just the '138 by tying one of the enables to the frame select.

    Bruno Saraiva said:
    But... if "there are many ways for the FSS to fail", and if you say it's not well implemented, one more reason I'll stick to the GPIO selecting!

    Yep, the frame select is dependent on SPI mode, it has timing restrictions in some modes and is not even available in others IIRC.

    I have seen one manufacturers documentation suggest they had implemented this 'correctly' allowing each chip select to operate in a different mode and independent of timing. They also allowed the chip selects to be used with a decoder in order to conserve I/O pins. SPI transactions would be queued up with a select number, number of bytes to transfer, input and output buffers. It should have made quite a flexible system but I never actually used it.

    Robert