• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 29 subscribers
  • Views 2271 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.

TIVA C series launchpad -GPIO Pins

Nikhil Kant
Expert 1130 points

I need a bytewide port from theTIVA launchpad. I am also using USB port  in host mode, so that whole of Port D is not available. Which port should I use? I do not want to mix and use bits of different ports. Are the lines  PA0,PA1 required for debugging/programming or can they be used in an application.

Regards

  • 0
    Guru 26105 points

    Hi,

    You can use PA0 and PA1 for whatever you need - on the Launchpad are assigned to UART0 to provide you with the hardware for a printf, if you need to use this function during debugging. 

    Petrei

  • 0
    Guru 117855 points

    It is reported that those here can never: "be too thin, too rich, or have sufficient GPIO."  I would bet - that at some point - you will wish PA0/1 remained free/able to serve as UART...

    While we note your distaste for multi-port, "mix/match" in such bytewide port creation - such is greatly simplified by the port masking w/in Stellaris/rebrandWare - and is a simple, one-time programming effort.  (detailed here - month or so past)

    Additionally - should/when your real-world needs expand - external SIPO (serial in, Parallel out) and/or PISO ICs enable the quick/eased creation of byte or wider ports.  Use of the MCU's SSI port simplifies such data flow - in both (read & write) directions...

  • 0 in reply to cb1_mobile
    Expert 1130 points

    Thanks.I can easily use other serial ports  if reqd. (though port A provides this functionality at reset ).  Port A happens to be dedicated to other lines too, that my be required for programming the device in application later. My I/O needs are not that great. Just need a byte wide port if possible.

    Regards

  • 0 in reply to Nikhil Kant
    Guru 47900 points

    Thank you - Port_A has historically (this brand & Stellar predecessor) been rich in serial capability - both UART and SPI.  Be cautious when "cut/pasting" set-up/config code of Port A's UART.   Other ports rarely include the default behavior afforded by Port A's UART - and thus require additional set-up/config program function calls to succeed.

    Beyond your byte-wide data port - suspect you'll need accompanying data strobes and level signals as well - thus a multi-port harvesting is most always required.  (thus the past mention of "serial to parallel" - which should confine the byte-wide requirement to a single port, providing both data & strobes/levels...)

    Requirements often expand (our findings) and if you are able to exceed your current GPIO signal needs - you may well save the time/cost/effort of a new board spin - downstream...

  • 0 in reply to cb1
    Expert 1130 points

    I am able to use PB0-PB7 as a bytewide port, since I have now learnt  that PB0 and PB1 are not required if using USB in dedicated host/device mode.

    Regards

  • 0 in reply to Nikhil Kant
    Guru 117855 points

    We've beaten this into submission - but do check latest/greatest errata for use of PB0/PB1 - as you seek. 

    In the past - (PB0 especially) exhibited certain unwanted behavior (impacting multiple, past MCUs) - when used as GPIO.

    Update: 08:50 CST - see now that TI's Lela G. has given "ok" for PB0/PB1 use as GPIO - under separate thread.   Unless PB0/PB1 "hiccup" - errata read (in that regard) may be of less urgency...

  • 0 in reply to cb1_mobile
    Expert 1130 points

    Checked the TM4C123GPM  errata. No unwarranted behaviour reported for PB0. Also section 18.2 of  MCU datasheet clearly states availability of PB0/PB1 if not using USB OTG functionality.

    Regs