• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 29 subscribers
  • Views 304 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.

more than one device on a spi port -- ie -- can one use alternative chip selects

Glenn Edgar
Prodigy 250 points
Other Parts Discussed in Thread: EK-TM4C123GXL

The spi_master.c program for the TM4C example uses the following pins.

//! - GPIO Port A peripheral (for SSI0 pins)
//! - SSI0Clk - PA2
//! - SSI0Fss - PA3
//! - SSI0Rx - PA4
//! - SSI0Tx - PA5

In the program, the chip select is controlled by the spi port rather than the user.

The launchpad pinlist for the EK-TM4C123GXL has the spi port as follows:

PB7 TX

PB6  RX

PB4   clk

For chip selects there are 

PE0,PA4,PA3

This does not fit the spi model where the chip select is integrated in the spi module.  Does this model work for the TM4C.  If so are there any code examples.

Thanks

Glenn

  • 0
    Guru 117855 points

    I interpret your writing as your desire to harvest, "readily available pins" from your L-Pad board.

    That said - there are over 100 posts here - detailing the rejection of the "native/automated" chip select (FSS) in favor of "user-chosen" GPIO to manage that FSS-like function.

    Method we use - w/success is to first insure that we've chosen the "best matched" SPI format - as demanded (not by the MCU) but by your SPI Slave(s)!  In that manner - you become responsible for asserting & deasserting FSS - in concert w/the individual slave chip's needs.  (i.e. insure that your signals comply w/slave's timing chart)

    May I emphasize the fact that our firm strives to use - as much of the "automated SPI process" as the MCU provides - as possible?  We "break" from that process (only) via the assert/de-assert of FSS - all other signals remain MCU-SPI - controlled/generated.  (there's little point in bit-banging when "automatic SPI" has been done (likely better) than you or I could do...)

    It's unclear how you've arrived at just 3 "chip select" pins.  In our usage - any available GPIO may serve as, "manual FSS" - as I've outlined herein.  You do not have to choose a pin which may (potentially) serve as "automated" SPI FSS - as the pin will be entirely "GPIO controlled" - any pin will do!  (which grants you great freedom in selection)

    BTW - we've done (exactly) that which you describe.  (talk to multiple SPI slaves via a single MCU SPI port)  On occasion - different slaves may have different SPI Format requirements - which complicates your (programming) life - but is not a, "deal-breaker."  (forces you to set-up/configure the MCU module as is appropriate for the addressed slave)

    Make sense?  Bon chance mon ami...