• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 783 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/TM4C1294NCPDT: Dynamically change pin function (GPIO, SPI)

svl123
Intellectual 690 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: STRIKE

Tool/software: TI-RTOS

Hello,

I am running TI-RTOS on the TM4C1294NCPDT microcontroller. My application requires the ability to dynamically change the function of certain pins (for example, PA4/PA5) between SPI mode and general GPIO mode.

I know that I can use the GPIOPinConfigure function to set pins for peripheral mode (SPI) but am not sure how to set them to regular GPIO mode afterwards. Also, does the GPIOPinConfigure function work once BIOS has been started?

Thank you,

svl123

  • 0
    TI__Guru**** 190806 points
    Hi,
    For example, after you are done with the SPI function and if you want to re-purpose PA4 as a GPIO output pin you can do:

    GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, GPIO_PIN_4);
    GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_4, GPIO_PIN_4); // To set PA4 high
  • 0 in reply to Charles Tsai
    Guru 117855 points

    Vendor's Charles has - following the poster's lead - answered poster's question.

    That said - as my firm has,  'Dynamically Re-Programmed FPGAs 'On the Fly' - successfully - for 20+ years - there ARE (other) points which should (often must) be considered!

    • first - without 'spelling it out' - poster (has) identified the, 'Lack of consistency' presented by the (API's missing)  'GPIOPinConfigure()' function!    Even should there be 'Tech reasons' for such absence - that should at minimum - be (somewhat) detailed.    Poster's question is completely valid.
    • bigger problems lurk - when such 'Dynamic Re-Purposing'  is contemplated (cb1 is believed to be 'first here' to employ that language)  - additional 'care/consideration' must be employed:
      • PA4 provides 'bi-di' SPI data or legacy SPI0TX - when in SPI Mode.    Now - as this pin is to be 'shared' - one must REALLY consider the implications - should the (other/shared) connected end - seek to 'Drive PA4 High!'    Should SPI mode be enabled - and PA4 set to transmit - AND the 'other/shared' connection (also) 'Drive HIGH' - we have,  (deadly)  'Output to Output CONTENTION!'   (what IS that smell?)    Strike ONE!
      • In addition should PA4 be in SPI mode - this time receiving - and the 'other/shared' connection (STILL) 'Driving HIGH' - the contention will shift to between 'other/shared' pin and the (remote) SPI device which will be transmitting!    And - pin PA4 - as an SPI_RX - is likely to prove 'confounded' - by such data contention!    Strike TWO!

    There ARE many (potential) benefits to such,  'Dynamic Re-Purposing'  -  yet a higher 'Degree of System Awareness' must be enforced.    And (pardon) - such appears to have been 'missed.'    'Interlocks' must be properly & regularly employed - to prevent 'Damage to components' - or the creation of 'illegal data' passage.    This (usually) means that:

    • the SPI Master, SPI Slave, and 'other/shared' device - must (somehow) KNOW the state of, 'ALL  devices - which 'tie' to PA4!'    Minus such (awareness) - trouble AWAITS!     And (that awareness) may prove 'tricky...'
    • so many of our firm's clients have 'had difficulty' in properly managing this (shared signal) implementation - that often - any/all benefits (via such alleged Pin-Saving) - fall by the wayside!

    Should not a 'Second Green Pennant' - be hoisted?

  • 0 in reply to Charles Tsai
    Intellectual 690 points
    Thanks! This is exactly what I needed.
  • 0 in reply to svl123
    Guru 117855 points

    Hold on - there is another post (earlier) - which presented a, 'considerably different  viewpoint!'

    Devil (luxuriates) in such details!    Might a  'System Approach' ...  trump an 'MCU Only' analysis?