• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 166 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.

MSP-EXP432E401Y: delay between bytes when transmitting over SPI

Andy Moore
Prodigy 55 points
Part Number: MSP-EXP432E401Y

I am attempting to use SPI to drive a string of of ws2812b neopixels. I am using an array of bytes to create the bit pattern that I want to send out to the LEDs, this is almost working, except that when I send my array of bytes out i can see (using a scope) that there is a delay of 710ns between each byte that is transmitted. Is there any way to reduce, or better still, eliminate this delay ?

  • 0
    TI__Guru**** 158915 points

    Hi Andy,

      The delay is inherent to the internal SSI state machine before starting a new transaction. I'm not sure if you are using the Simplelink SDK SPI drivers or directly the SSI peripheral drivers. Calling the SSI peripheral drivers may shorten the latency slightly but the delay between transactions will still be there as it is inherent to the hardware.  

  • 0 in reply to Charles Tsai
    Prodigy 55 points

    that's a shame - I'll try re-writing my code to use the delay as a zero...

  • 0
    Expert 1431 points

    Hi,

    By chance, I have just implemented an SPI interface to an MRAM. I assumed that using the TI driver with DMA in a TI RTOS project would throw bytes at the device as fast as possible but, after your comments, I thought I better check Slight smile
    The MRAM will clock at up to 40MHz which is what I was using but my poor scope probe ground was struggling a bit so I've started at 1MHz.

    Yep, there's the gap between bytes - about 2uS.

    Next I tried 5MHz.

    The gap appears to have shrunk to about 400nS, so seems to depend on the clock rate!

    Next 20MHz.

    Now we seem to be down to 100ns.

    Finally, 40MHz.

    Now we are down to about 50ns.

    These are all fine for my application, but good to know!

    Thanks

  • 0 in reply to Jim Whitehouse
    TI__Guru**** 158915 points

    Hi Jim,

      Thanks for showing these waveforms. I will bookmark this post in case someone asks the same question. Looks like the internal state machine waits about 1 SPI clock before starting a new transaction. 

  • 0 in reply to Andy Moore
    Prodigy 55 points

    many thanks for everyone's input. I'm now making use of the delay as the trailing zero for each 'bit' that I am sending & I've increased the bitrate for the data - the pattern I am getting works perfectly driving my pixels.

    In the trace below, each spike represents a bit, the first 8 bits represent the value sent to the green pixel. The narrow spikes are interpreted by the neopixel as a zero & the wider ones as a 1 -  I have sent a value of 11

    what I am actually sending out as data is either 0xF0 for the narrow spike, or 0xFF for the wider spike