Day 4 of the ARTS challenge check-in --- For STM32, how does the team use version control (git) in conjunction with CubeIDE? (Review)

foreword

(1) All English blogs are written in such a grand way that I really can’t understand them. I haven't found any other English blog sites with a slightly lower threshold. Here is a discussion I saw on reddit to share.
(2) Link to the original text: https://www.reddit.com/r/embedded/comments/15idc39/with_stm32s_how_do_teams_use_version_control_git/

question

With STM32s, how do teams use version control (git) with CubeIDE?

How does the team use version control (git) with CubeIDE for STM32?

I’m wondering if someone could give a walkthrough of where they clone to, what the folder structure should be within the reop, etc. Our team is having trouble managing it.

I was wondering if someone could explain where they cloned to, what the folder structure should be in the reop, etc. Our team is having trouble managing it.

How do teams manage a testing config (on a dev kit) vs. the deployment (on a custom PCB), with similar-but-different IOC files? Any advice?

How does the team manage test configuration (on the development kit) and deployment (on the custom PCB) using similar but different IOC files? Any suggestions?

Looking for advice for small teams of 2-10 people.

Seek advice for small teams of 2-10 people.

Short reply

In the following answers, there are too many people complaining about cubemx, and many persuade them to quit using cubemx (wry smile). So I summed up the solution of continuing to use cubemx.
(1) In the development using cubemx, the whole team should unify the version of cubemx. Otherwise, the kernel code may be different due to version differences, and you will face the risk of generating incompatible code.
(2) During the process from the beginning of development to the end of development, the version of cubemx should not be upgraded. The reason is the same as above.
(3) Never put some custom code in special generated comments, because the code generator will remove these codes.
(4) Try to abstract the code away from the hardware. This feeling is more appropriate.
(5) It is highly recommended that you figure out how to port the code generated by Cubeide to vscode or anywhere else, and write your own build scripts. It doesn't take too long and makes things easier. (I don't understand this)
(6) Here, I think examples will help better. The Cube code is located in Core/, which is included in main.h. Then all additional peripheral classes will include main.h.
https://github.com/jasonyang-ee/STM32G431KB

Guess you like

Origin blog.csdn.net/qq_63922192/article/details/132115885