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.

TM4C129EKCPDT: How to realize long SPI frame

Part Number: TM4C129EKCPDT

Hi,

We are trying to make MCU interface with 3 LED matrix driver chips. The MCU needs to support 48-bit(16*3=48) long SPI frame (The driver chips are daisy chained on SPI, and every chip is 16-bit wide). When I say 48-bit frame, I mean we need the SSInFss signal to go low during the 48-bit frame transmission and go high after the transmission is over.

Is the QSSI module capable of doing this?

Thanks,

Tianlei

  • Tianlei Zhang said:
    The MCU needs to support 48-bit(16*3=48) long SPI frame.    Is the QSSI module capable of doing this?

    In general - your answer is "Yes" - providing these guides are followed:

    • Use of the (more complex/capable) 'QSSI module' proves 'over-kill' - you're better advised to employ a more standard (SPI/'SSI') module
    • Do not employ the 'SSInFss' signal nor pin (*) - instead use another GPIO pin - which you can 'Command to logic low' (and remain there) throughout your (entire) 48 bit sequence
    • The Led matrix drivers you describe (usually) will accept the 'slight delays' - occurring necessarily between your 'multiple SPI transmissions.'
    • The SSI clock signal connection should be as short & direct as possible - and avoid passing near to 'high currents and/or high data rate signals or traces.'

    (*)  Provided you configure the SPI's 'candidate/default' SPInFss pin (instead) as a GPIO Output  - that pin may well serve your purpose...  (it is easily driven 'low' - throughout your 48 bit flow)

  • Hi Tianlei,

     Yes, you can use the SSIAdvFrameHoldEnable(). Please note you can use the SSIAdvFrameHoldEnable() only if you are in the Advanced mode with a call to SSIAdvModeSet(). 

    . Please see below. 

        // Hold the Fss pin low during transfers. The Fss will be controlled directly
        // by the SSIAdvDataPutFrameEnd(). If calling SSIAdvDataPutFrameEnd to
        // write data to the FIFO, the Fss is de-asserted for the corresponding data.
        SSIAdvFrameHoldEnable(SSI0_BASE);

  • Hi cb1 and Charles,

    Thanks for the reply and the information is very useful.

    Tianlei

  • Hello Charles,

    Neither staff nor I had (ever) 'seen or known' of that  (assumed reasonably new) API feature/function.

    Recall this poster seeks a '48 bit long' SPI transaction.     Does 'Advanced Mode'  - and that special/added 'frame hold' function - 'persist over poster's entire transaction?'    (again 48 bits)    BTW - if so - is there ANY limit to this function's 'hold?'

    Seems like, 'Substantial Added Work'  (and attention) - when contrasted w/the far simpler, 'GPIO Clear & Set!'

  • Hi cb1,

      The advanced mode with frame hold is a feature to TM4C129 QSSI only. It can be held low as many frames as needed until you stop it with the SSIAdvDataPutFrameEnd  for the last frame.  The benefit of it over GPIO is that the deassertion of Fss can be as short as one SPICLK between frames. For TM4C123, the GPIO method would have been the only method of doing it which you suggested so well. 

  • Thank you, Charles - and indeed - that's new knowledge for our group.

    The LED Driver chips our 'thoughtful/awarding'  poster is using are (usually) broadly accepting.    (SPI data arriving in 'regular clusters'  should 'cause no issues' - yet might 'elements' of that new/advanced 'SPI' function prove more burdensome - and 'extend the time between (successive) SPI data transfers?'    (all of these while the Fss line is held low)    

    Staff even recalls several of your 'past' posts - mentioning this 'delay between successive SPI transfers' as a (sometimes) concern.   (we believe the MCU was commanding a high-precision ADC - and you alerted (that) poster to the 'potential for difficulty' - due to the 'staggered arrival' of SPI clocks & data...)     And sure enough - w/in a month or so - we encountered that (exact) issue - and solved it via (glorious) 'bit-banging.'