Pin names with "_" and "-" have the same effective output name in C code (main.h)

[Lloyd1968]

I am using STM32CubeMX (Version 6.17.0).

 

Here is what happened. I created a PIN name "CLK-A". After some troubleshooting, I found a mistake in my pinout definitions. I named the correct pin as "CLK_A". However, I did not delete the "CLK-A" pin.

 

When the C code was generated for the project, the "CLK-A" pin was defined as "CLK_A" in the output C file. The tool did not flag me that there were two pins with the same effective name. It took me some time to track down the issue. Once I deleted original "CLK-A" pin definition, my design worked. 

I added "CLK-A" back to the design on another pin". I got "CLK_A<pin name>" in the "header.h" file. The first pin defined seemed to have priority.

 

 

[Andrew Neil]

CubeMX also allows names with spaces, and changes the spaces to underscores in the generated C code.

I haven't tried with other characters that  are not legal in C; eg /CS ...

[Lloyd1968]

I was hoping that your software would do a check to let the user know that there would be a naming conflict.
FYI- The STM IDE and MX code are my favorite programming environment. I recommend it every time that someone starts a new project.

[Andrew Neil]

---

@Lloyd1968 wrote:
 your software 

---

It's not my software!

This is a community forum; most contributors are just users like you - not ST staff.

How to identify ST employees

 

---

@Lloyd1968 wrote:
let the user know that there would be a naming conflict.

---

Yes, that would be helpful!

@Ghofrane GSOURI It's one thing to have the behaviour documented, but it would still be helpful to get a warning in the app when this happens.

[Andrei Chichak]

The pin names get turned into #defines in main.h. For the C preprocessor to handle these defines properly they have to use a character set that is compatible with the name rules of C.

Name rules in C allow a leading underscore or [a-z,A-Z]. Then you can have {_,0-9,a-z,A-Z}. Notice, no leading numbers (confused with numbers, octal, hex) or any periods, commas, ampersands, octothorps, carets, splats, openrounds, closerounds, you get the idea. These characters would tell the parsers to go in weird directions trying to recognize the context of your identifiers. C is from the '70s, this was hard, so it's not in the language.

CubeMX lets you put lots of stuff in the pin names, and if your EE used early versions to set up your project, you will know that EE pin names do not play well with C compilers. ST altered CubeMX to sanitize the pin names to give C compatible names. It's a good thing. Can you imagine someone who is new to C trying to fix code with this included:

#define CS* PIN3

 That looks like a multiply to C, but to an EE its an active low pin.

[mfgkw]

This is true.

But it would not forbid CubeMX to warn about duplicate sanitized names.

[Ghofrane GSOURI]

Hello @Lloyd1968 @mfgkw @Andrew Neil @Andrei Chichak 

Your findings match exactly what CubeMX is documented to do, and they also explain why you saw the behavior with CLK-A / CLK_A. What the documentation says:

1- Label normalization rules:

Labels must start with a letter or _.
They must not include special characters like -, (), [], etc.
Any special character is replaced by _ in the generated #define name.
So:

 CLK-A → normalized to CLK_A
 CLK_A → already valid, stays CLK_A

2- Duplicate labels :If there are duplicate labels (after normalization), CubeMX

Keeps the original label as‑is for the first pin.
Adds a unique suffix <Port><Pin> for the next ones.

/* Private defines -----------------------------------------------------------*/
#define CLK_A_Pin GPIO_PIN_0
#define CLK_A_GPIO_Port GPIOF
#define CLK_AG7_Pin GPIO_PIN_7
#define CLK_AG7_GPIO_Port GPIOG

 

THX

Ghofrane