Is there any possible that users can change parameters generated by STM32 CubeIDE and use their own constants to maintain code?

[WXiny.1]

I noticed that some documents about STM32CubeMX mentioned that, but I don't know how to use it with STM32 CubeIDE.

[chaaalyy]

I´m not sure, if i get the point here... But as i read that question, there would be an easy way to "override" ANY codegenerator (CubeMX, TouchGFX and so on):

a) place a define in usercode-section at top of main ( like " #define USEOWNPARAMETERS ")

b) just above the generated Code (of course also in usercode-section !) you place " #ifndef USEOWNPARAMETERS { "

c) at the other end in the next usercode-section after the generated code: }

#endif

#ifdef USEOWNPARAMETERS {

own_parameter_1(do something); //maybe copied and modified from generated code...

own_parameter_2(do something);

}

That way, a generator can generate, whatever it want´s to do, you just have to ensure, not to miss something. You can copy/paste the generated code just to the part with "own_parameter.....", modify however you want to and it´s save from being overwritten ;)

/Charly

[WXiny.1]

Thanks for your reply.

You do offer a solution to avoid code generator changing user's code, but that also means users need to maintain two codes. Actually what I need is a method to use code generator and user cosntants together, which means users can protect codes generated by IDE from code generator after they change codes. But if users need to add some new peripherals they can still get a template with IDE.

I thought this is a widely request, but I cannot foud it in any document.

[chaaalyy]

As far, as i know, just the sections between " /* USER CODE BEGIN xxxxxx */ " and " /* USER CODE END xxxxxx */ " are protected against being changed by the generators. So the method i use, is as above: It´s the trick to "encapsulate" the generated code with Brackets in these user sections, depending on what is defined. Then i take the generated code, copy it into the user section and there it can be safely modified.

Of course: If you change (or add) something with the generator, what is needed by your application, it will be placed into the part, "owned" by the generator and you also have to just copy that into your own section after being generated.

That way, the generators can still work properly and modify, whatever they want. Their code is just ignored by the compiler... Your own code stays untouched but of course needs to be maintained by yourself then ;)

If the original files get too long and too confusing that way... just outsource your own code into new files and call just the according functions in the "original" user sections.

[WXiny.1]

Actually I found users can set their own constants in "User Constants " section just beside the "Parameter settings " section of each peripheral, but it's very limited which means you can only use it when you need to set a specific number while choosing a configured parameter is the most common situation. Although it doesn't have much use, I really think it is a correct direction. If I can set all parameters with my constants instead of choosing from HAL macros, it will be much easier to develop with this IDE.

[n2wx]

I think this is the only support for the feature you're seeking. A simple #define that appears in the Private defines section of main.h. But you could have done that yourself. I suppose it helps organizationally if you're already using the configurator to prepare your peripherals for real but I'm not so sure it just doesn't create more headaches by giving you one other thing apart from the source code that you need to keep track of.

[WXiny.1]

Thanks for reply.

I can understand your concern, but it's more convenient for me to manage parameters in a .h file when the project is nearly completed and there's no need to worry about the main code. I think split configure part with control part of the code would make my code structure clear. But it looks like ST wants users to manage parameters only by code generator.

[chaaalyy]

Well ... You still have the possibility, not to use the generators at all and do everything by hand on your own ;)

If you still want to use MX, choose the MCU at the beginning, not a board. Then you can configure every pin, however you want, as long, as it has the hardware capabilities, you need...