How often do you use the pin config and code generation stuff? I do 2-3 projects a year and don't bother with that stuff at all. For pin config, I create a spreadsheet with the pin mappings. That takes about a day, but that's a tiny fraction of the overall time I spend on a project. I'd rather do that than use the automated pin config stuff in STM32CubeIDE but then be saddled with a sluggish IDE for the rest of the project.
Again, I'm in complete agreement with you, and I do a lot more projects per year than you. What I do is whenever I start to use a new MCU, I take the time to make a pin define file for that particular MCU/package type, along with macros and/or functions whereby I can access any pin by the pin number, rather than the chip manufacturer's designation. As an example, take the PIC16F877A 28-Pin PDIP, SOIC, SSOP, where Pin 2 is RA0/AN0. I would have a macro or enumeration of "PIN2". Then I'd have a header file for all pins on the MCU organized according to interfaces, and define the net name in terms of the pin number. So, let's say Pin 2 (RA0) is a system LED. I'd have a board header file where I define:
#define SYSTEM_LED PIN2
#define LED_ON 0
#define LED_OFF 1
Then when I initialize the pin, I call a function like this:
gpioOutputInit (SYSTEM_LED, LED_ON, GPIO_ATTRIBUTE_NORMAL);
And set the pin via:
gpioOutputSet (SYSTEM_LED, LED_OFF);
Or toggle the pin via:
gpioOutputToggle (SYSTEM_LED);
The function gpioOutputInit is defined such that it will initialize the pin as a GPIO output, with an initial setting high or low, and setting additional attributes that the particular pin might have, such as pull-up/pull-down, etc. Likewise gpioOutputSet and gpioOutputToggle work as you'd expect.
So I always access all GPIO pins by the net name, not some port number or such. I totally cringe whenever I see Microchip code written like:
TRISA = 0xac;
LATAbits.LATA0 = 0;
What if I suddenly want to swap the system LED from pin 2 to pin 28 (RB7)? I have to modify the TRIS initialization, and every point where I turn the LED on or off via the LAT statements. It's a totally ridiculous way of programming an MCU, in my opinion, other than as some learning experience, or for some very basic project that won't need many changes after the design is fixed. For my projects, there's an initial board, and almost always pins are changed around before the final board, and often numerous times in between. Plus using the net names makes the code much more self documenting. And if we decide to totally change the MCU to a different family or even different manufacturer, no problem. For at least all the GPIO pins, I only need to change one header file with the new pin numbers, not needing to know anything about which port that is on a particular MCU, etc. Or to change the LED from active low to active high, I just change in the board header file two definitions for LED_ON and LED_OFF, rather then hunting throughout the file for each occurrence of LATAbits.LAT0 and swap the value used. For simple peripherals, I also do something similar. So for SPI, I2C, UART, I can just define a port number, and then later if I want to change to use a different port, I make the change on place in the board header file. Of course there's a limitation to what can be done. There's certain things that are just so MCU specific, that they can't be generalized across all varieties of MCUs. But at least 90% or more of the code is portable.
Anyways, Sal, as you do, I start out with a spreadsheet of my MCU pinout. Then from that, I create my board header file, and then do the code. Whenever I want to see which actual pin is a certain function, I just open the board header file, no matter what the MCU is, and all the pins related to a particular interface are right there organized in one grouping. I never need to deal with an automated pin configuration tool which is going to be different for each manufacturer, and just a step to slow me down whenever I need to change things around. Now if I'm on a brand new MCU family, and especially if there's a big hurry to do it, or if it's a one-off project using that MCU, I might use the manufacturer's automated pin configuration tool, and just be done with it, rather than spend the time to generate the necessary code and header files to deal with it in my standard format. But those cases are few and far between. Generally I use the same MCUs over and over again for project after project, and I find my method saves a ton of time and headaches.