• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 28 subscribers
  • Views 321 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Reading SSInRX pin value as GPIO

Michael Stich
Expert 1505 points

I'm using a TM4C129x chip.  I have external flash on the SSI bus running in legacy mode.  The flash will output its busy status on its SO line (MCU's SI) when CE (chip enable) is pulled low. (I'm manually running the CE line in code) Is it possible to read the SSInRX pin state via the gpio data register when the pin is configured for SSI operation?

Thanks,

Mike

  • 0
    Guru 47900 points

    I don't know your exact answer but - if a free gpio exists - that would seem a, "foolproof" way to achieve your objective...  (i.e. you'd route that external SO line into MISO and gpio_x.)

    Experimentation may also - quickly - reveal...

  • 0
    Intellectual 905 points

    Yes, you should be able to read the GPIO state even if the pin is configured as a peripheral function.  Provided it is a digital peripheral.  I don't think this works with analog mux.

    However, I agree with CB1, if you can spare an extra pin then route the signal to both pins.  That is a more future proof and vendor proof method. 

  • 0 in reply to INTEGRIS Dexter
    Guru 47900 points

    INTEGRIS Dexter said:
    That is a more future proof and vendor proof method. 

    Never had I even considered, "future-proof" - that's a great get Dexter. 

    Use of surplus pins so often simplifies/proves the concept.  Too early attempts at, "perfection" are a major cause of project delay/derailment - and such, "need for perfection" exists (again too often) only in the mind/heart of the sole developer...  (small biz knows better - build & deliver on time - perfect later - as/if that's ever required...)

    Deliver to client spec/requirement - downstream is "time plenty" for pin-saving/other "perfection."

    [edit] 14:23 24 July:  thinking bit more - suspect it's possible to, "briefly/temporarily" free MISO from it's SPI role - direct as GPIO input - and then loop/read your status.  Once, "ready" revert to SPI and voila!  (as no SPI clocks have been generated - no glitch or other harm (that I can quickly id) seems to invade/torment this (alleged) "fix"...