• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 1619 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/EK-TM4C1294XL: Where to find pin indexes/names for ek-tm4c194xl

Alberto Zohan
Prodigy 215 points
Part Number: EK-TM4C1294XL
Other Parts Discussed in Thread: TM4C1294NCPDT, TM4C1230C3PM

Tool/software: TI-RTOS

This sure feels like a dumb thing to have to ask, but here goes. I first learned to use TI's boards using the TM4C123G and just TivaWare, so when we wanted a pin index, we'd use driverlib/pin_map.h. Now I'm developing on the 1294 within RTOS and am wondering if the pin_map.h is still valid for pin addressing (the rtos training warned that tivaware's libraries weren't necessarily compatible). If pin_map.h isn't valid, where can you get the pin names?

I tested the pin map file by creating a new rtos project using the "empty" template which has the heartbeat function by default. For the GPIO_write() and GPIO_toggle() calls, I switched the index with the one for the pin map index which goes to the same led (PN1) and then added "#include <pin_map.h>". The program hung right at the first GPIO_write() call, so I have to assume that the pin map header isn't valid. So where do I get the pin indexes?

  • 0
    Guru 117855 points
    Should yours be a "dumb thing to ask" - move over my friend - staff/I are in the same boat!

    Are there not, "Vendor Supplied - Guaranteed to Work" projects - thru which you can, "Glean your answer?" (make NO changes - you want the many benefits of "Vendor Supplied" - which in theory - manages the arcane - and should reveal that which you seek...) (one hopes)
  • 0
    TI__Guru**** 190456 points
    Hi Alberto,
    Please refer to the EK_TM4C123GXL.c file after you create your RTOS project. Look for GPIO_PinConfig gpioPinConfigs[] and you will see the GPIO pins in the array. These pins are arranged in the order matching the index defined in the EK_TM4C123GXL_GPIOName in the EK_TM4C123GXL.h header file.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    Hi Charles,

    Poster did note he has "moved to "4C1294" - bit obscure - yet may indicate some (change) required....

    I quote, "Now I'm developing on the 1294 within RTOS." 

  • 0 in reply to cb1_mobile
    TI__Guru**** 190456 points
    Hi cb1,
    Thank you. You are correct. I was reading the problem description about TM4C123. The idea is the same. He should look at the EK_TM4C1294XL_GPIOName in the EK_TM4C129XL.h file to find the enumeration of all the GPIO signals used by RTOS. And in the EK_TM4C1294XL.c file under the GPIO_PinConfig gpioPinConfigs define the pin attributes (strength, direction, type, interrupt edge and etc).
  • 0
    Guru 13040 points

    Alberto,

    Just to make sure I understood... does the content available on chapter 23 of the datasheet have the information you need?

    That chapter has:

    23.1 Signals by Pin Number (on entry for each of the pins on the MCU, listing all the possible functions of that pin number)

    23.2 Signals by Signal Name (an alphabetical list of the peripheral functions, and their respective possible pin assignment)

    Regards

    Bruno

  • 0 in reply to Charles Tsai
    Prodigy 215 points
    Charles,
    I thought that would be the place to look as well, so I checked it before asking here. Unfortunately, the EK_TM4C1294XL_GPIOName enumeration in the ...1294XL.h file only lists the user switches 1 and 2 as well as LEDs D1 and D2. I tried opening the name declarations to see if maybe they were sourced from another file, but nothing.

    The gpioPinConfig array contains the same pins (I started this project with the "empty" rtos template, which toggles the LED in a heartbeatFxn task). I added my own entry: GPIOTiva_PE_0 | GPIO_CFG_INPUT | GPIO_CFG_IN_INT_BOTH_EDGES. I really don't know whether the pin direction macro is correct, but that's another issue. The GPIOTiva_PE_0 comes from GPIOTiva.h and i tried using that as the argument to GPIO_read, but no luck.
  • 0 in reply to Bruno Saraiva
    Prodigy 215 points
    Bruno,

    I'm not sure we're looking at the same datasheet. I got the datasheet for the TM4C1294NCPDT from www.ti.com/.../getliterature.tsp. Chapter 23 of that one is regarding PWM generation.

    Chapter 26.4 (GPIO Pins and Alternate Functions) lists the PE0 and its potential uses, but I wonder which of these, if any, is the index I need? For a GPIO_read() call, is it as simple as the pin number, or does it depend on how you're using that pin? Specifically, I'm trying to capture rising and falling edges of a signal between 0.7V and 4.3, but I would also like to understand the general answer so I know what to look for when I want to do something else.
  • 0 in reply to cb1_mobile
    Prodigy 215 points
    cb1,

    I've looked through the Resource Explorer for GPIO examples to aid in this search and there is only one. Coincidentally, this has almost the exact same data as the "empty" RTOS template I referred to in my response to Charles. For all of the GPIO-module-specific function calls (GPIO_toggle, GPIO_setCallback, GPIO_enableInt), the same enumerations are at the root. For example, the EK_TM4C1294XL.h has the ...1294_GPIOName array initialized with EK_TM4C1294XL_D1, but I have no earthly clue where that designation comes from or how to adapt to use any other pin - PE0 in my case. It seems like each example takes the same route: <program>.c file ==> board.h ==> EK_TM4C1294XL.h and the trail stops there.

    I have this eerie feeling I'm missing something super obvious, but it escapes me still.
  • 0 in reply to Alberto Zohan
    Guru 13040 points
    Alberto,

    You are looking into the right chapter (or at least you are looking at what I was talking about) - the point was to remind that the MCU datasheet has a chapter with a complete list of pins, and what functions they can perform.

    It appears that what you are missing is actually the part number definition in your project. Take another look at pin_map.h file... It has MANY almost-repeated blocks of pin addressing. Each block is typed for one specific part number, and is enclosed, for example, by:
    #ifdef PART_TM4C1230C3PM
    #endif

    On your project settings you need to add a definition macro matching the MCU you are using. If you work with CCS and select the proper device, I believe that such definition will automagically appear in CCS Build -> ARM Compiler -> Predefined Symbols. I recommend you waste some time and explore the project properties configurations, even with the advanced settings enabled (there's a couple of thousand things there, but after some staring they will start to make sense - while some of them never will).

    Now, when you refer to specific functions, such as GPIO_toggle, the parameter to it MUST be explained in the related documentation. This particular call is not a Tivaware function, it is possibly a xxRTOS? The API guide is the location that will provide details on how is the pin parameter supposed to be passed.

    Hope that helps! Let us know.

    Bruno
  • 0 in reply to Alberto Zohan
    Guru 13040 points
    Alberto,
    Next to my reply above, I forgot to warn: do NOT apply 4.3V into the TM4C129. It will be an expensive manner of learning that 129's are not 5V tolerant, as opposed to 123's.
    Regards
    Bruno
  • 0 in reply to Alberto Zohan
    Guru 117855 points

    Returning to the "dumb things department" (i.e. "my department") would not your progress be aided by (temporarily) KILLING the RTOS - which appears the major culprit in your present plight?

    Note that you are (now) FIVE DAYS - and ELEVEN POSTS - into your investigation.       And a,  "welcome shore" - appears no closer...

    Freed from the "entanglement/limitations/distractions" this RTOS presents - would not your "odds of success" RISE - and w/that success - you'd glean key "understandings" - which remain hidden - while under "RTOS dictates!"       It should be noted that,  "No case for RTOS use has been made"  - and the MCU's "SysTick" stands ready/able to provide (some) such,  "RTOS-Lite" capability...  (while avoiding RTOS "meddling" - which blocks your progress...)

  • 0 in reply to Alberto Zohan
    TI__Guru**** 190456 points
    I'm currently out of office. I have no access to my PC at the moment. When you add a new pin you must update the EK_TM4C1294XL_GPIOName first. Let's say there are already 4 enumerated pins in EK_TM4C1294XL_GPIOName. You might add a new pin, (your PE0). The PE0 will become the fifth element in EK_TM4C1294XL_GPIOName. In the gpioPinConfig you will then define the pin type for PE0 (i.e. direction, interrupt edge )as the 5th element in the gpioPinConfig array. The order (which is 5th element) must be maintained for the new pin between the EK_TM4C1294XL_GPIOName and gpioPinConfig.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    One here has the impression that we are, "Bailing faster" ... yet the canoe is "still" sinking!

    Filling that expanding "hole" (i.e. yanking that "RT (non) OS")  - appears best,  "lifeline to shore."