• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 1398 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.

RTOS/CC2640: CC2640: SPI0 with multiple Chip Selects

Matthias Mueller
Intellectual 380 points

Part Number: CC2640

Tool/software: TI-RTOS

Hi Forum

I searched the forum quite a bit and I didn't find any solution which fits my usage.

I have a custom board with a SPI sensor and a SPI Flash, both use the same SPI bus (but different CS of course). I'm now curious, how I could use the SPI driver to fit both chip selects.

I use the SPI driver via SPI_MODE_CALLBACK, and have already written a running system with the sensor. Now I want to add the FLASH functionality and I have trouble to do the correct approach:
Do I rather

  • make a new SPI1 handle, which shares the same MISO, MOSI and SCK pins as the SPI0 device, but with another CS? Is it possible to do this? The SPI0 handle is then used to access the sensor and the SPI1 handle is used to access the Flash?
  • Do I reconfigure the SPI0 every time I use a different CS? If so, should I first call SPI_close, then SPI:open with the other index and params?

I don't want to use the CS as a dedicated GPIO, because I can only reset the CS in the SPI transfer finish callback function, and there I need to start a new transaction right away: the time which a CS-GPIO pin is high would then be too low!

I really hope you can understand my question and my issues and could give me an elegant solution.

Best Regards,

Matthias

  • 0
    TI__Genius 11740 points
    Hi Matthias,

    I'll ask around the office and see what some of the experts think about what the most elegant solution would be.

    I know one potential power saving solution is by doing the bitbanged SPI via sensor controller. (which you can just have the same SPI interface with GPIOs as CS lines) It's not using the SPI driver however, so there's that. But at the same time it's low power, as the M3 can be sleeping.

    Regards,
    Rebel
  • 0 in reply to A. Rebel
    Intellectual 380 points

    Hi Rebel

    Thank you very much for your fast reply. A low power solution is always a good solution and this sounds very intriguing... But I'm not sure if this would fit in the current application and if this solution could fulfill all my requirements. I'll look into that, and I'll keep you posted if I have any solution using the sensor controller.

    But I would still be very interested what the other experts in your office would think about the best solution. This would be also interesting for further projects, and for now by far the fastest solution for my problem (I did never anything with the sensor controller).

    Thanks again and best Regards,

    Matthias

  • 0
    TI__Mastermind 20480 points

    Mattias,

    1. While the SPI controller has a hardware CS pin, the expected CS behavior may or may not work as you'd expect. See the SSI controller's timing diagrams for the various PHA and POL settings. If the CS pin assertion behavior isn't compatible with your design requirements, then you don't have a choice but to use a GPIO pin for your CS.
    2. An SPI handle is per SPI controller, not per device on the SPI bus (e.g.One handle per bus)
    3. From the driver's perspective, the controller can operate w/o an assigned CS pin. I think in your application, you should probably assign a dedicated GPIO pin per SPI slave and ensure that you have the correct slave selected perior calling SPI_transfer().

  • 0 in reply to Tom Kopriva
    Intellectual 380 points

    Hi Tom

    Thank you for your answer.

    I guess, that is the way to go, by using a dedicated GPIO pin. But I am very cautious to go this way, because I will set the GPIO pin high in the SPI transfer-finished-callback, which could immediately trigger a new SPI transfer for the next command for the same device. If I use GPIOs, the CS could be very shortly high in this case (maybe too short), minimum 150ns is required. But this is only 3.6 clock cycles with a CPU speed of 24MHz which should be fine... Even optimized assembler isn't that fast :)

    I will try to implement this with GPIOs and I will get back to you if it's not working, or mark your answer as solution if it works.

    Thanks again

    Best Regards,
    Matthias