I'm interested in hearing other people's views on the pros and cons of configuring and managing a project's Device Cube framework API by using STM32CubeMX as opposed to the classic RTE_Device.h
I started work on a new project a while ago (STM32F429) and elected to to go down the STM32CubeMX path as I was working on an STM32 demo board before our hardware was ready. Doing it this way allowed me to play around with peripherals and setups and get some things up and running quite quickly. Once our hardware was ready, I reconfigured pins/peripherals etc. to get my code working on the new hardware.... great.
CubeMX is no substitute for reading the datasheet, nor does it cover the configuration of all peripheral use cases, so one will always have to change what CubeMX generates to tailor it to one's needs.
Now once past that point, going back to CubeMX to change things can mess you around if you haven't stuck to the rules of only changing/adding code in the /* USER CODE ... */ areas. Plus as time goes on the need to change something in CubeMX drops away completely.
I then became irked by the project folder structure surrounding the "STCubeGenerated" folder which contains the generated initialisation code, plus those /* USER CODE ... */ regions all over the place just looked messy. I felt as if I didn't have enough control over the project, so I restructured things to my liking. There were just too many levels down there.
Now I'm thinking about starting a new project (on similar hardware) and I'm wondering if I should try the Classic RTE_Device.h method. It seems that I can have better control over folder structure.
Anybody have experience with both? It seems you have to use one or the other, so which one is better? Will this method continue to be supported?
Any thoughts would appreciated.
If anyone's interested, I did go down the Classic Cube API framework path on a subsequent project and was a lot happier with things.
The reason I used CubeMX in the original project was because our customer requested it. (I come from the land of Eclipse and using make files for building).
I later convinced them to allow me to use the classic path on the second project as I felt CubeMX is more a tool to get those unfamiliar with the platform up and running quickly, but those with more experience may leave them feeling too abstracted from things (maybe that is the whole point of CubeMX). Others will differ of course.
Another point: If you're using the KEIL middleware drivers, it was simple too because when configuring them via RTE_Device.h, they take care of all their own hardware associated initialisation without having to set it up yourself (or involve CubeMX). Now you will say that is still abstracted from the hardware, but it seems there are only two paths to follow when using the middleware drivers, CubeMX or RTE_Device.h.
Just my 2c. YMMV