cancel
Showing results for 
Search instead for 
Did you mean: 

Inconsistent pin naming

Andrew Neil
Super User

I've always found it a little irritating:

#define CLK_A_Pin       GPIO_PIN_0
#define CLK_A_GPIO_Port GPIOF

Why is it deemed necessary to have "GPIO" in one, but not the other?

 

Surely, that should be either:

#define CLK_A_GPIO_Pin  GPIO_PIN_0
#define CLK_A_GPIO_Port GPIOF

("GPIO" in both),

 

Or:

#define CLK_A_Pin  GPIO_PIN_0
#define CLK_A_Port GPIOF

 ("GPIO" in neither)

 

(There isn't a label for "suggestion" - so "bug report" is the nearest option)

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
1 ACCEPTED SOLUTION

Accepted Solutions

Hello @Andrew Neil 

Your change request ID is  #0060783 

I will keep you posted with updates.

 


@Andrew Neil wrote:
I haven't had a chance to try CubeMX2 yet - does the same apply there?


Any question related to MX2 should be posted in the MX2 forum, where you can receive complete technical support from the dedicated team.

STM32CubeMX2 (MCUs) - STMicroelectronics Community

THX

Ghofrane 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

9 REPLIES 9
Ghofrane GSOURI
ST Employee

Hello @Andrew Neil 

I believe your request is valid and reasonable.
It will improve clarity and consistency, especially in larger projects, and will also help with code readability and maintainability.
I am raising this change request with our development team.

THX

Ghofrane 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.


@Ghofrane GSOURI wrote:

I believe your request is valid and reasonable.


Thanks.

I haven't had a chance to try CubeMX2 yet - does the same apply there?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Hello @Andrew Neil 

Your change request ID is  #0060783 

I will keep you posted with updates.

 


@Andrew Neil wrote:
I haven't had a chance to try CubeMX2 yet - does the same apply there?


Any question related to MX2 should be posted in the MX2 forum, where you can receive complete technical support from the dedicated team.

STM32CubeMX2 (MCUs) - STMicroelectronics Community

THX

Ghofrane 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

mƎALLEm
ST Employee

I do agree with @Andrew Neil , meanwhile that may break completion of previously generated code of user projects.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

@mƎALLEm wrote:

I do agree with @Andrew Neil , meanwhile that may break completion of previously generated code of user projects.


I agree. It should be an option for the user to select a different pin naming. The default should be backwards compatible. 


Personally I think pin and port both need to be uppercase. It's convention to have #define constants all upper case.
So I would prefer if it was something like this:

#define CLK_A_GPIO_PIN  GPIO_PIN_0
#define CLK_A_GPIO_PORT GPIOF

 

 

Kudo posts if you have the same problem and kudo replies if the solution works.
Click "Accept as Solution" if a reply solved your problem. If no solution was posted please answer with your own.
Andrew Neil
Super User

@mƎALLEm @unsigned_char_array  Yes, there would be an issue if an old project were opened in a newer CubeMX which made this change.

That should, at the very least, give a warning.

Preferably an option to change or not.

 

@Ghofrane GSOURI I forgot to say that my preference would be for both names to not have the "GPIO"; ie,

#define CLK_A_Pin  GPIO_PIN_0
#define CLK_A_Port GPIOF

I'm all for brevity; the "GPIO" seems entirely redundant.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

@unsigned_char_array wrote:

I think pin and port both need to be uppercase. It's convention to have #define constants all upper case


Agreed.

But this would affect all #define symbols generated by CubeMX - not just pin/port names.

Maybe start a separate thread for that ... ?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

@Andrew Neil wrote:

@unsigned_char_array wrote:

I think pin and port both need to be uppercase. It's convention to have #define constants all upper case


Agreed.

But this would affect all #define symbols generated by CubeMX - not just pin/port names.

Maybe start a separate thread for that ... ?


To my knowledge only GPIO macros have lower case in them. But I could be wrong. 

Kudo posts if you have the same problem and kudo replies if the solution works.
Click "Accept as Solution" if a reply solved your problem. If no solution was posted please answer with your own.

@unsigned_char_array wrote:

To my knowledge only GPIO macros have lower case in them. But I could be wrong. 

Also applies to User Constants; eg,

Image1.png

 

Although these are all user-entered - so, if you want an uppercase-only policy, then don't enter lowercase in any of these fields.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.