complement or replace CubeMX?

[po221]

Hello

I am using CubeIde and cubeMx on a project for several years with no issues.

But I am facing today a limit of CubeMx:
On a STM32L431RCTx I need to have UART2_RX on PA15 and PA2 as GPIO_EXT, not as UART2_TX. CubeMX forces me to have PA2 as UART2_TX :(

I also can't easily use "USER CODE BEGIN/END" areas because CubeMX uses elseif which I can't split (see attached image)

1) Is there a trick to mixing MX setups and personal setups (and this "elseif" not nice)?
2) Is it better to configure everything manually? if so, what is the best practice?

Thank you very much in advance

PS : I'm using CubeID3 1.13 with STM32Cube FW_L4 V1.18.0

[Pavel A.]

In single wire mode, the pin used is always the TX one, even for RX only. This is how STM32 works, this is not a Cube bug or limitation. Cube knows all alternate functions of all pins. Don't blame it before checking the RM:

https://www.st.com/resource/en/reference_manual/rm0394-stm32l41xxx42xxx43xxx44xxx45xxx46xxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf  p. 38.5.12

Note that the USART has another config bit , CR2 bit 15, which swaps TX and RX pins in hardware.

[po221]

No choice of overload anyway because the option "Do not generate the main" does not prevent the main.c from being overwritten by CubeMx.

@Pavel A.  There my project is demolished but I am almost certain to have succeeded yesterday evening in overloading PA2 as GPIO_EXT while PA15 was in UART2_RX.
It would be a shame to lose an unused pin

[Pavel A.]

>1) Is there a trick to mixing MX setups and personal setups (and this "elseif" not nice)?

Yes there is a trick, but too hacky. TL;DR it's not worth it.

> 2) Is it better to configure everything manually? if so, what is the best practice?

3-way merge of changes in the cube-generated code into your actual project code. 

[po221]

Yes, I'm having trouble finding a clean solution to mix cubeMx configurations with my configurations. it puts code everywhere to do the same thing.

With 3-way merge solution, I then need to remove CubeMX. Is it enough to delete the .ioc file for that?

[Piranha]

Effectively the only "useful" thing RubeMX does is initializing peripheral. So it's a code, which initializes a structure and calls HAL_..._Init() function. Literally a few lines of code, which can be written in a minute. And the pin configuration, which you will override anyway... How is all of this circus "easier" than just spending a few minutes for writing a few lines of code? I'll remind it again - RubeMX generates just the initialization, not your application code. Therefore it "helps" with a code, which normally takes less than 1% of the total development time. Just stop for a moment and actually think about it!

[po221]

Yes Cube MX "only" initializes peripheral but in doing so it allows
1) to save infinite time (much more than 1%) in reading the datasheets thanks to all these details that we discover are important and that we would not have seen in the first exhaustive reading
2) to gain the same time in the discovery and understanding of the HAL

I'm going to waste time rewriting what CubeMx does very well in order to be able to apply the necessary modifications to what it doesn't manage, but it won't be much compared to already saved time.

A huge thank you to those who designed CubeMx even if I blame them a little for PA2 and UART2 🙂

[Pavel A.]

> Literally a few lines of code, which can be written in a minute. 

haha. a minute... if you copy-paste. Or have AI interface chip in the brain ))

>  it "helps" with a code, which normally takes less than 1% of the total development time

And don't forget 2-3  (typically) reviewers who will ponder on these lines, and then maintainers.

[Pavel A.]

> It would be a shame to lose an unused pin

Yep. This is why STM32 has the single wire mode. The RX pin will be released and you can use it as you want. (As Piranha noted, Cube does not support the RX/TX swap with single-wire yet. Or does it already?)

[Pavel A.]

> With 3-way merge solution, I then need to remove CubeMX. Is it enough to delete the .ioc file for that?

Yes. the .ioc and .mx files. I always use CubeMX instead of IDE to edit .ioc files, this gives freedom to keep the .ioc anywhere, not just where CubeIDE wants to, and rename them. So I keep them with the schemes and other documentation.

[Piranha]

to save infinite time (much more than 1%) in reading the datasheets

That time is spent once, contrary to fighting with RubeMX, which requires an infinite amount of time - you will do it for every peripheral in every project again and again endlessly.

to gain the same time in the discovery and understanding of the HAL

Yes, that is also a waste of time because...

what CubeMx does very well

There is no such thing. Literally almost all code in HAL/Cube is broken and bloated. And, like I already said, it cannot even receive uninterrupted USART stream without ridiculous workarounds.

A huge thank you to those who designed CubeMx

They are incompetent and that is the reason why the HAL/Cube is a beginner level junk, which is not only useless but even harmful for any serious purpose.