2024-04-11 12:22 PM
Which file and where in the file (between begin .. end marker) should I place my function?
This is taken from Drivers\STM32WLxx_HAL_Driver\Src\stm32wlxx_hal_gpio.c.
It says "HAL_GPIO_EXTI_Callback could be implemented in the user file"
I understand that the MX code generator requires user code be placed as dozens of specific
places. How does those "places" work? Do those "places" not erased if I reconfigure pinout with
another run of the STM32CubeMX code generator? TIA
/**
* @brief EXTI line detection callback.
* @param GPIO_Pin Specifies the port pin connected to corresponding EXTI line.
* @retval None
*/
__weak void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
/* Prevent unused argument(s) compilation warning */
UNUSED(GPIO_Pin);
/* NOTE: This function should not be modified, when the callback is needed,
the HAL_GPIO_EXTI_Callback could be implemented in the user file
*/
}
2024-04-11 12:42 PM - edited 2024-04-11 12:44 PM
Generally you should create (and add to the project) your own C files, and put your stuff there.
Of course in your own files there are no begin-end markers.
The EXTI callback is a good candidate to live in your own file.
Use version control as early as you can, to save your work and protect precious changes from deletion by mistake or because of Cube bugs.
2024-04-12 05:36 AM
Many thanks. Very good advises. I did not used version control before. Where should I start? Is that part of the STM32Cube system or needs an external version control software? If so, which software to use for small number of code lines, team of one, may be a few in future. TIA
2024-04-12 05:48 AM
Please use this button to properly post source code:
@David_ wrote:Which file and where in the file (between begin .. end marker) should I place my function?
You place it anywhere that that makes sense for it to be!
The markers just mark places that CubeMX will preserve when it re-generates code.
There is nothing special or magic about these positions - it's all just standard C source that is fed to the standard C compiler.
@David_ wrote:I understand that the MX code generator requires user code be placed as dozens of specific
places.
No, it doesn't require you to put things in any specific places - it allows you to place code wherever makes sense for your application.
As @Pavel A. said, putting stuff in your own source & header files gets you away from all this.
2024-04-12 05:57 AM - edited 2024-04-12 06:11 AM
@David_ wrote:I did not used version control before. Where should I start?
Start with whatever you've got!
Do you have any history at all?
@David_ wrote:which software to use
Nowadays, Git is pretty much the go-to standard.
You can have a free repository on GitHub - it can be private.
Other services are available; you can even host your own.
Eclipse certainly has integrations to work with Git - don't know if that actually makes it into the STM32CubeIDE.
It is by no means necessary to have Git (or any other VCS) integrated into the IDE - you can just manage it at the file level. That's the way I do it.
2024-04-12 06:04 AM - edited 2024-04-12 06:11 AM
git in IDE , see ->
Solved: How can I use git in stm32CubeIDE. - STMicroelectronics Community
How to use Github with STM32cubeIDE in 2023 - Shady Electronics
2024-04-12 06:30 AM
@David_ About version control, it's hard to advice something specific. Git is a common place these days and there's a lot of software and tutorials on it. Try github if you already have a Microsoft account. The Github's GUI for Windows (Electron-based) is easy for beginners.
Another useful IMHO variant is Fossil - especially in isolated environments without internet connectivity.
I don't use GIT clients built into various IDEs, because of so many reasons.
2024-04-12 07:05 AM
@Pavel A. wrote:I don't use GIT clients built into various IDEs
Likewise.
I just manage the files - rather than having to mess about with different clients in each different IDE