2021-01-24 07:49 PM
Hi!
We have a lot of problems with the automatic code generator. One of them. Sometimes we need to make changes to 'Drivers'/'Middlewares' and store them in our svn repository. If we include these libraries to our project via 'externals' and do code generation, then we will lose all our modifications.
For example: we use PHY which cannot be managed by the existing 'HAL_ETH_Init' function (in Drivers/Src/stm32f4xx_hal_eth.c). We want to change the duplex and speed logic, but cannot.
Maybe there is a way to add our scripts for execution before and after code generation?
Thanks for your reply.
2021-01-25 01:53 AM
See CubeIDE embedded MX code generation delete custom preprocessor symbols
Possibly .extSettings file usage is going to help you
2021-01-25 03:24 AM
Thanks for the fast reply
Could you provide an example how to prevent code generator make any changes under specified file using .extSettings (Drivers/Src/stm32f4xx_hal_eth.c for example) ? As I know, files from the 'Drivers' directory are simply copied from STM32Cube \ Repository . It looks like '.extSettings' is intended to solve other problems and cannot help us.
2021-01-25 05:25 AM
I've got a trial myself. Sounds .extSettings file working fine but not able to promote a custom file having same name than one managed by code generator already.
Not working:
[Groups]
Drivers/STM32F0xx_HAL_Driver=../MySrcCode/stm32f0xx_hal_i2c.c
Working:
[Groups]
Drivers/STM32F0xx_HAL_Driver=../MySrcCode/stm32f0xx_hal_i2c_mine.c
Maybe best is so to patch your local FW pack content ... this way will be considered by code generation ...
2021-01-27 08:43 AM
So CubeMX code generation provides a half-broken and bloated HAL drivers, very bad ETH driver, terrible lwIP integration and trivial write-once initialization code, which accounts for a 0,...% of the total code. And on top of that it adds an endless stream of problems, which one wouldn't have, if one would write their own code. Isn't it obvious that code generation just drags the projects down?