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

[AScha.3]

and can you (i dont have this chip, but all similar ) define in Cube half duplex? then only one pin is used.

 

 

[po221]

I would have loved

I would have loved to do like that but when I put PA15 in UART2_RX, UART2 is not configurable (red mode)

Thanks

[AScha.3]

yepp, on half duplex the "TX" pin is used, pa2 here. but now you get pa15 free to use...for exti.

or try alternate pin: first set uart ...as it wants. pa2+15 . then hold ctrl key and click mouse on the pa2 pin + hold key, then blinking all possible alternative pins. if this is something you like, just click on the alternative pin and select ...uart..here. then it uses this pin.

[Nikita91]

Selecting half duplex MX selects PA2!

PA2 in the only pin for USART2_TX and MX persists in selecting this pin when USART2 is selected.

If we put PA2 in reset state USART2 is automatically disabled.

Same behavior with USART3.

It seems that MX does not allow to use an UART for RX only. For me it's a bug... Because I commonly do it without using MX.

[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]

Yes, no alternative for USART2_TX and I don't have free pin

[po221]

I imagined 2 solutions to bypass CubeMX:
1) Check "Do not generate the main" in Cube MX and rebuild a main that uses some of what CubeMX generated and some of my own code.
2) Let CubeMx generate the initializations and override at the end with my own modifications

Could one of these solutions be the correct one? what else ?

[AScha.3]

if Cube otherwise doing good job for you, i would keep it,

and set uart as it likes.

then after init in main you write to port mode (MODER..) and switch mode for pa2 -> input.

and set exti 2 . and write void EXTIx_x_IRQHandler(void) in xxxit.c .

[Piranha]

For normal mode selecting "Receive Only" or "Transmit Only" doesn't release the respective unneeded pin. For "Single Wire (Half-Duplex)" mode enabling the "TX and RX Pins Swapping" doesn't move the single allocated pin from Tx pin to Rx pin, which is what the hardware actually does. That's just what RubeMX is. And what's the point of all of this contraption? The HAL broken bloatware cannot receive USART stream without ridiculous hacks anyway. Toss it all away and develop a useful and working code:

https://github.com/MaJerle/stm32-usart-uart-dma-rx-tx

 

CubeID3

How can "E" be misunderstood for "3"? Does your eyesight mirror some single letters?

[po221]

There's ID3 in my company name, fingers go faster than eyes

I'll attempt an overload of what CubeMX does.
Little by little the overload will be able to take more and more things from cubeMX.

[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.]

> 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.]

>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?

[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]

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 :)

[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.

[Nikita91]

A huge thank you to those who designed CubeMx

---

Not so huge...

MX restricts the use of UARTs since it does not allow you to configure a UART in RX only (simply by not defining a pin for TX). The designers just didn't think a UART could be used like this.

While this is possible very easily outside MX

This is one of the difficulties with this kind of generator: impossible to think a priori of all the possible uses by hundreds of thousands of users!

The other is to respond to everything that can be imagined with a single code: it is necessarily very heavy...

[po221]

Thank you all

I merged my project and removed CubeMx and now I structure the project again by managing the inits more efficiently, without the CubeMx framework but keeping its syntax.

I have a bogus project on the side with CubeMx to test configurations and keep the advantage of CubeMX.

THANKS