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.

CCS/TM4C_PINMUX: Why are my pin names not reflected in any useful way in the generated code?

Part Number: TM4C_PINMUX

Tool/software: Code Composer Studio

Hi, I just completed entering the pinout of my project (using a TM4C1294NCPT) in the TI Pin Mux Tool (offline version, see below). The generated code is most likely going to set the I/O pins in the state I wanted them.

But I put much effort in giving each I/O pin a meaningful name in the tool, but none of those names show up in the generated code. I was hoping to get some #defines in the generated code so I can later reference them with my given name when toggling pins and such. They are not even referenced in the the doxygen comments created around each pin's init code.How stupid is that?

Some competitor manages to provide at least a #define for FANCY_NAME_PORT and FANCY_NAME_PIN for each GPIO defined in their tools, so it can be easily referenced from the code.

Do I overlook something or is it really not meant to be in this way?

Markus

  • Hello Markus

    While it is possible to add a define for the GPIO Number it is not possible to add the name for the GPIO Port number. The real issue comes when multiple IO's are assigned the same name and they are distributes across different ports. The tools checker may not work as expected.
  • Hi Amit,

    Pardon but "that redundancy of name" seems unlikely to rise to anywhere near, "Real Issue" status - does it not?
    Poster seems most capable - his request seems (extremely) fair & proper...

    Perhaps like "oj" - we need a search for the "real" killer issue...

  • I just wanted to point out, that I simply cannot believe noone thought about making the "alias" names given by the customer available in the C code. When it not even used on the graphical representation of the chip pinout, nor does it show up in *any* of the output files, why you would need them in the first place.

    I tried to make suggestions on how to drastically improve the customer value for this tool with very little effort. Competitors are miles ahead with their tools....

    Markus

  • I don't understand the issue here. I just need the GPIO_BASE_ADDR defined for that pin name and the bit number.

    So let's assume I name my pin "REL_OUT_N" in the tool, and it sits let's say on port PN3, the tool needs to generate in the header file:

    #define REL_OUT_N_GPIO_BASE (GPIO_PORTN_BASE)
    
    #define REL_OUT_N_BIT (GPIO_PIN_3)

    So I can access it like

    GPIOPinWrite(RELAY_OUTPUT_N_PGPIO_BASE, RELAY_OUTPUT_N_BIT, 0);

    if I wanna set the output low.

    That's basically all I ask for. Cannot really be that hard or?

    Markus

  • Hello Markus

    Defining something like "#define REL_OUT_N_BIT (GPIO_PIN_3)" is not difficult. It is the Base Address that is going to be more difficult as there is no field to do so. We could always suffix _GPIO_BASE to the Name field.

    The tougher issue is when users input more than 1 GPIO under the same name, as it may be across the port base address.
  • Amit Ashara said:
    It is the Base Address that is going to be more difficult as there is no field to do so.

    Amit, I read this a couple of times but didn't really get it... I believe that Markus' suggestion is kind of "text based only", and there seems to be no problem in having the pinmux create the output lines that he suggested:

    #define REL_OUT_N_GPIO_BASE (GPIO_PORTN_BASE)

    After some time, every developer here probably created his own "convenient method" for the HAL definitions of his board pinout. I did defend/use the PINMUX once, but eventually gave up and came back to copy/paste/edit because the tool was incomplete. And I second the opinion that a complete "definitive" PINMUX should be the way to go, so that the pin mapping task could be more mechanical and consistent across users and projects.

    Bruno

  • Hello Bruno

    We have already highlighted the fact to the tools team. It would require the Pin Mux tool to be updated to be able to handle such a scenario. At the same time there is a complexity of multiple ports being selected with a single name. We can provide indexing but again, it is not guaramteed that folks would like the same.
  • I still don't know what "multiple definitions with the same name" you are referring to. The user entered alias name can be just checked for uniqueness. Problem solved.

  • Hello Markus

    In the menu that you have pasted, there is an entry for "Number of GPIO Pins" which by default is set to "1". This can be changed to 2 or more, in which case the user can select a different port as well. This is what we want to address when working a solution. The reason is that when we generate the define for the base address, some users would like to have multiple options, some would like to have indexed, while others would be of the opinion that the tool does not work for their use case. There is no one size fits all.
  • I honestly would have no idea why anyone would have the need to have the same name assigned to multiple pins. That just doesn't make any sense. Even if you think of an Address Bus, each bus line would have a diffent name like "ADDR_0", "ADDR_1" and so on. I really think this multiple selection thingy is superfluous.
  • Hello Markus,

    When making a Bus, it may not be necessary that the "logical" bus are mapped to the same Port Base. As an example, a Bus may have 4 pins from Port A which serve as address, 2 pins from Port B which serve as control. Though it would be advised to use them as separate define names, some folks would want to to have the same define with indexing to cover the same. Then comes the question of how the indexing should work since some would like to have MY_BUS_PORT_0_ADDR and some would like see MY_BUS_PORT_ADDR_0.
  • I see. I still think it would be a good start to just generate the names as suggested further up and maybe check for unique names. This is very easy to implement and would be totally sufficient for 90% of the users I'd say. Declare it as experimental if necessary.
  • Hello Markus

    I agree. As of now what we can provide is a single pin option which allow the assigned NAME to be prefixed by _PIN and _PORT for the defines to be generated. Again w.r.t the snapshot what would be generated is

    #define SHT_DATA_PORT GPIO_PORTH_BASE
    #define SHT_DATA_PIN GPIO_PIN_1

    Will something like this work for the moment when using a single pin? This may be easy to implement w/o changing the tool.
  • That would be perfect for me.
  • Hello Markus

    Can you please try the following patch file?

    Replace the attached files in the directory where PinMux V4 is installed. On my machine it is installed under D:\ drive

    D:\ti\pinmux_v4\pinmux\deviceData\TM4C129x\templates\driverlib

    Do rename the file as pinout.c.xdt and pinout.h.xdt (Please do note that this is not an official release or the final solution)

    pinout.c.xdtpinout.h.xdt

  • Hilarious! That's all I need! Thank you so much!
  • Hello Markus,

    Please do note that I have tested the generation of the code but not the compilation or test behavior.
  • For me it compiles my project. I cannot test right now if the behavior changed, but if I notice issues, I let you know.

    It already increased the readability of the init code by 500% if you read something like that:

        //
        // Configure the GPIO Pin Mux for PL7
    	// for GPIO_PL7
        //
    	MAP_GPIOPinTypeGPIOOutput(LCD_D15_PORT, LCD_D15_PIN);
    	MAP_GPIOPinWrite(LCD_D15_PORT, LCD_D15_PIN, 0x0);
        //
        // Configure the GPIO Pin Mux for PK4
    	// for GPIO_PK4
        //
    	MAP_GPIOPinTypeGPIOOutput(LCD_CS_N_PORT, LCD_CS_N_PIN);
    	MAP_GPIOPinWrite(LCD_CS_N_PORT, LCD_CS_N_PIN, LCD_CS_N_PIN);
        //
        // Configure the GPIO Pin Mux for PK5
    	// for GPIO_PK5
        //
    	MAP_GPIOPinTypeGPIOOutput(LCD_RS_PORT, LCD_RS_PIN);
    	MAP_GPIOPinWrite(LCD_RS_PORT, LCD_RS_PIN, LCD_RS_PIN);
        //
        // Configure the GPIO Pin Mux for PK7
    	// for GPIO_PK7
        //
    	MAP_GPIOPinTypeGPIOOutput(LCD_WR_N_PORT, LCD_WR_N_PIN);
    	MAP_GPIOPinWrite(LCD_WR_N_PORT, LCD_WR_N_PIN, LCD_WR_N_PIN);