• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 754 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.

EK-TM4C123GXL: Multiple slave devices on one SPI interface

user5843847
Prodigy 60 points
Part Number: EK-TM4C123GXL
Other Parts Discussed in Thread: TM4C123GH6PM

Hello:

We are looking into the best way to have multiple slave devices on a same SPI interface in the Tiva C series. Can some GPIO lines be used as chip select lines (and asserted independently before the start of the SPI transfer) independently of the SSixFss line of each interface? If this is possible, which will be the state of the SSIxFss line when the SPIx interface transfer is active?

Any help, hits and suggestions will be really appreciated! 

Dario

  • 0
    TI__Guru**** 191296 points

    Hi,

      Yes, you can use the GPIOs as chip selects( in one-hot fashion) to select your slave devices. 

  • 0 in reply to Charles Tsai
    Prodigy 60 points

    Thanks! Meaning that even the SSIxFss line can/should be configured as GPIO for CS purposes? Dario

  • 0 in reply to user5843847
    TI__Guru**** 191296 points

    That should be fine. 

  • 0 in reply to user5843847
    Guru 117855 points

    Hello,

    Do note that the "SPI group's SSInFss pin" will follow that particular "SPI format & mode directives!"    (which may or may not suit your application)

    Use of a "Non-SPI" GPIO pin is "Free from all such signal management restrictions' - providing you w/much added design flexibility...

    As you noted an interest in multiple SPI devices - and should you seek to "save" MCU pins - you may employ simple address decoder ICs!     (which satisfy vendor Charle's 'One Hot" output note.)     (i.e. 3 GPIO provide up to 8 unique SPI chip-selects)

    And one more time - perhaps "unexpectedly" - it is the remote/slave SPI Device which dictates the "SPI Format" to be employed!    (Such may be reasonable as the MCU enjoys capabilities beyond those of "humble" SPI Slaves...)

  • 0 in reply to cb1_mobile
    Prodigy 60 points

    Exactly!

    My question came upon looking at the table 15.1 (page 954 of the Tiva TM4C123GH6PM datasheet). According to the wording in the paragraph previous to the table, the exception to the rule of "Most SSI signals are alternate functions for some GPIO signals and defaults to be GPIO signals at reset", includes the SSInFss lines. I'm trying to gain clarification on the operation of this line when a SSIn interface is active. If I'm reading Charles's answer correctly, the SSInFss line can still be defaulted to the GPIO and used in the standard old fashion "assert-transmit-de-assert", which it wasn't clear for me while reading the DS. Direct question: When performing an operation on any SSIn interface, will the corresponding SSInFss be asserted or not? i.e Can the SSInFss line be used as another independent chip select line in conjunction to other GPIOs or no matter the usage of a GPIO as CS, the SSInFss line will be still asserted? Also, in section 15.4 of the DS (Initialization and Configuration) it is not clear what would happen to the SSInFss lines. 

    Would you kindly elaborate on the "SPI format & directives"?

    Thanks!! Dario

  • 0 in reply to user5843847
    TI__Guru**** 191296 points

    Yes, the SSInFss line can be defaulted to GPIO. You will do something like below. If you don't use the PA3 as an SSI0Fss then whatever SPI format (phase and polarity) has no bearing on PA3 to be used as a GPIO. 

    GPIOPinConfigure(GPIO_PA2_SSI0CLK);
    GPIOPinConfigure(GPIO_PA4_SSI0RX);
    GPIOPinConfigure(GPIO_PA5_SSI0TX);

    GPIOPinTypeSSI(GPIO_PORTA_BASE, GPIO_PIN_5 | GPIO_PIN_4 | GPIO_PIN_2);

    And you can use whichever GPIO pin (including PA3 or others) you want to as your CS for your slaves. 

    Of course, you need to activate your GPIO for CS active first before you call the SSIDataPut() and then de-assert your CS again. 

  • 0 in reply to user5843847
    Guru 117855 points

    Responses follow:   Ay Carumba - vendor's Charles has beaten my crack young team to the punch!    (but not to the advantaged, pin-saving use of address decoder IC.)

    user5843847 said:
    the SSInFss line can still be defaulted to the GPIO and used in the standard old fashion "

    Indeed - by not initializing/configuring SSInFss into SPI Mode - it continues as GPIO.

    user5843847 said:
    will the corresponding SSInFss be asserted or not?

    It will only assert as SPI if initialized/configured into SPI mode.

    user5843847 said:
    Can the SSInFss line be used as another independent chip select line

    Yes it can - but this (may) lead to confusion so my team does not recommend it.   (down the road - your code review may not recall that SSInFss was "Liberated from automatic SPI duty!)

    user5843847 said:
    kindly elaborate on the "SPI format & directives"?

    Both the MCU Manual & the Peripheral Driver Library provide strong/solid detail, here.   From the '123's manual: "Programmable interface operation for Freescale SPI, MICROWIRE, or Texas Instruments synchronous serial interfaces."   In addition:

    15.3.4 FrameFormats

    Each data frame is between 4 and 16 bits long depending on the size of data programmed and is transmitted starting with the MSB.  There are three basic frame types that can be selected by programming the FRF bit in the SSICR0 register:

    ■ Texas Instruments synchronous serial

    ■ Freescale SPI

    ■ MICROWIRE  

    Note that the MCU manual nicely details each.   (i.e. provides the signal organization & other usage directives...)

    Appears that vendor's Charles (he has 1000 Green Resolves) and this humble outsider/reporter (w/only a few Green resolves) have earned your Green Stamp - have we not?

  • 0 in reply to Charles Tsai
    Prodigy 60 points

    Thanks a lot! Got it. The clarification I was looking for. Dario

  • 0 in reply to cb1_mobile
    Prodigy 60 points

    Yep. Address decoding was always my to go solution. Just wanted to be sure that the SSInFss lines/pins can be used as GPIO for the decoder. Seems the case, which means - great, no pins wasted!! Thanks for your help!

  • 0 in reply to user5843847
    Guru 117855 points

    My friend - you have awarded a "this Resolved" to yourself.    Two others have responded to your request - it is THEY who should receive such Green Stamp.

    Vendor's horrid choice of "Verified" continues to confound forum users.   The proper word is clearly RESOLVED - by stamping those (answering/resolving) posts - new readers may efficiently FIND the answering post.

    [edit] - with only the minimum of prompting - Poster has done the right thing!   Vendor & "escapee/outsider" offer thanks & smooth sailing...