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.

SPI problem with CS



Hi Support,

We have little problem I would love to get your input and expertise on MSP430 microcontroller (MSP430F5529A)

I am attaching 2 snap shots TEK00011 TEK00012 (the same image in deferent zoom )

As you can see MSP SPI in GPIO Chip Select  get delay from the moment of getting the Chip Select to “0” the clock is delay until 18uS – and we need to have only delay of 1 uS

Other wise the slave is not detected the connection as SPI – do you have any idea to solve the problem thanks

 

  • I guess the green line is the CS lien and the yellow the SPI clock?

    The CS is not controlled by the SPI hardware. It's a software-controlled GPIO pin. The SPI starts to clock the data with the next SPICLK cycle after tossing something into TXBUF. Whether CS is low or not, as it does not care for it.

    So if there is a delay, t is because of soem software overhead between asserting the GPIO pin that acts as CS and starting the SPI transfer by writing something to TXBUF.

    This is why I don't like HAL-type library functions - too much unknown overhead. Convenient if it works, and troublesome if things get tight.

  • Thanks for your answer.

    What libs do you think will be better to use?

    Do you have an example for such app. that will not cause that type of overhead.

    In general the application is connecting 1 SPI MASTER (single master) and 3 SPI SLAVES.

     

    Thanks for your help

    Shai

  • Shai Aharonov said:
    What libs do you think will be better to use?

    Whenever latency times are important, I stay away from any kind of lib. My own SPI code is a set of inline/macro functions which are compiled directly into the place they are used.
    If you call a function, you have the overhead of the function call, the overhead of saving any registers which are used (not knowing whether they are used by the callign fucniton at all) and you invalidate the 'transfer registers' inside the calling function. All this adds up to a lot of clock cycles.
    Compiling the code directly where it is used, is much faster.

    When stuffing an SPI with full core speed, you have just 8 clock cycles to read the next byte and stuff it into the SPI (or you'll suffer preformance loss). A function call alone will take longer.

    Shai Aharonov said:
    In general the application is connecting 1 SPI MASTER (single master) and 3 SPI SLAVES.

    So you assign a port pin for eachslave, chain all slaves to the same SPI, and when you want to do something, just pull one of the port pins low and stuff teh TX register - either with the byte(s) you want to send or with a dummy byte so you receive something.

    If the SPI is slow compared to MCLK (at least a factor of 10), then you might consider using interrupt functions for the data transfer. For everything faster, do it inline, busy-waiting, or setup a DMA channel to handle it.

**Attention** This is a public forum