• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 363 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/TM4C129XNCZAD: QSSI synchronization

John Duquette
Intellectual 710 points
Part Number: TM4C129XNCZAD

Tool/software: Code Composer Studio

I have two SSI devices that each need their own (Q)SSI peripheral (no CS on device).  These two devices will always be read together.  Is it possible to synchronize two QSSI peripherals so I can use a common clock pin for both devices?  I'm not I/O limited on the TIVA, but I am pin limited on the connector between the TIVA and the devices, so a shared clock pin would be a great help. 

Thanks. 

  • 0
    TI__Guru*** 134845 points
    Hello John,

    I want to make sure I am interpreting your vision correctly.

    Are you suggesting trying to use a single SPI CLK line, but have dedicated MISO/MOSI pins for each device?

    And in that scenario, want to be able to trigger a read with just one clock but with data being sent/received from two different sets of MISO/MOSI lines?
  • 0 in reply to Ralph Jacobi
    Intellectual 710 points
    Yes, Ralph. Your understanding is correct. I'll have 5 signals instead of 6 with the shared CLK line.
  • 0 in reply to John Duquette
    TI__Guru*** 134845 points
    Hello John,

    I see, that is what I feared because it is not possible to make that setup work to read in sequentially with TM4C MCUs as each SSI CLK is tied to a specific SSI peripheral, so you can't use the SSI CLK from SSI0 to also read/write with SSI1.

    Furthermore the described setup also doesn't allow for the use of Bi or Quad SSI modes because those just allow for data to be sent to a single device with less clock cycles (usually to interface with SPI Flash ICs).

    I don't think you are necessarily out of options though if you can get away with sequential reads of the devices, and don't mind a little added cost in terms of external logic.

    If you can accept those conditions, then what you could do is use tri-states to control the output the MOSI/MISO signals to one device, read data, and then swap them to the other device to read data from it. So you'd be back to having 5 SPI lines again going to the device, and 3 SPI lines plus 4 tristate control lines from the TM4C MCU. I can't help but wonder if maybe there is an inverse mux available actually, as that's really what we'd be trying to achieve here... to switch the MOSI/MISO signals from one set of outputs to another set. Might be worth looking into as well.

    Sorry that this isn't exactly an ideal solution, but due to how the SSI peripheral is configured, that's about the only workaround idea I have.
  • 0 in reply to Ralph Jacobi
    Intellectual 710 points
    Thanks Ralph, that is what I figured. Your comment on the BiSSI is interesting. Maybe I could run CLK to both devices and tie DAT0 to one device and DAT1 to the other device so they share a common clock, and then post process the data to reassemble the odd bits into one message and the even bits into another message. Does that sound possible?
  • 0 in reply to John Duquette
    TI__Guru*** 134845 points
    Hi John,

    That's a crafty idea and in theory it could work for transmitting... but I don't see how you'd be able to tell your slave devices to send data back in that same format unless you also have an MCU that controls them to that level. Furthermore, you'd have to make the slave devices transmit the data back on what would essentially be the "MOSI" line. If you think those devices can be manipulated to that extent or you don't need them to talk back to you, then it could work but otherwise I think the receive challenges make it non-viable.
  • 0 in reply to Ralph Jacobi
    Intellectual 710 points
    Luckily I have two identical slave devices! Thanks for your help.