用了一段时间CubeMx  感觉还是有些不足，
1 不支持函数或任务重命名，如果在CubeMx里强行重命名函数或者任务名 ，用起来就会造成原来的旧函数被清掉，
比如 在Cube中希望重命名一个任务函数，直接在原来已有的函数配置表中修改是不行的，这样会导致旧函数被删除，
目前的办法是 建立新的希望的函数后，手动把旧函数的内容剪切过来，然后删除旧函数，
2 随意写注释，
使用CubeMx后 注释不能再随便写是麻烦的事，主要是因为你一旦在CubeMx中对配置进行了更新， 在新生成代码时就可能把原来的
部分注释清除掉，

我感觉应该有办法让CubeMx在新创建代码时忽略用户注释的办法，但是目前还不知道，谁知道的话 就请教一下
还有什么心得 大家来补充

在论坛参与问题讨论分析解答的过程，其实就是一个自我学习的过程，碰到网友提出的问题，自己没有遇到过，通过分析测试，知识点就到自己的信息库中，在以后碰到时就不会花太多的时间去绕弯路，同时分享自己的方法也可以让广大的网友借鉴使用，确实是个两全其美的途径，希望大家各种参与进来，共同使用好ST芯片，充分发挥它的潜力，造福世界。。。

如果用cube做freertos的工程  建议你都选择任务在外部声明，然后任务你可以单独用一个或者多个.c写，这样cube就只帮你建立任务，分配空间，并且每个任务都做好了extern的声明，你在自己的.c改任务名，再同步在cube这边修改一下就ok。cube新建的工程不会修改你自己建的.c文件和工程目录。但是你要在cube生产的代码里面改东西，一定要在user code begin / end里面改。相比传统方式， 感觉用cube改起来感觉要方便很多，占用的资源一目了然，各种配置也可视化了。不用花很多时间配置底层，也不容易出错。

首先，/* USER CODE BEGIN Init */ /* USER CODE END Init */之间写代码，是不会被清掉的。。。其次，Cube启的函数名字干嘛要改呢？这么来说，一套API接口，有专门的人维护，而且还有专门的人搞，对于我们这些使用者来说，只要好用，那必须是拿起就是用啊！！！目前，我HAL和LL都用，感觉不错，不过LL的缺点就是资料有点少，非常接近寄存器配置！！！不过使用方式和HAL差不多吧。。。至少我目前是尽量把HAL和LL使用方式接近！！！

我觉得HAL里串口发送t函数和串口接收函数的__HAL_LOCK(huart)是冲突的，不知道为什么这样设定

在用户段复制？

MrJiu 发表于 2018-6-20 11:09
首先，/* USER CODE BEGIN Init */ /* USER CODE END Init */之间写代码，是不会被清掉的。。。其次，Cube ...

在RTOS 系统中 ，创建的 任务函数名，变量名 ，可能在后期需要调整，改变任务名称，邮箱名称

50031185 发表于 2018-6-20 11:16
在RTOS 系统中 ，创建的 任务函数名，变量名 ，可能在后期需要调整，改变任务名称，邮箱名称 ...

RTOS啊，这些组件类的，我都是直接从原先的官网下载的，Cube工具又封装了一波，我个人认为不好。。这么来说吧，我就把Cube当作MCU的外设初始化用了。。。其他东西没必要参考。。。

MrJiu 发表于 2018-6-20 11:21
RTOS啊，这些组件类的，我都是直接从原先的官网下载的，Cube工具又封装了一波，我个人认为不好。。这么来 ...

这个确实 有利有弊， 弊端是 对于原始的系统 改变了操作函数接口，有时搞得人摸不清方法， 好处是上手容易，适合新手，
做复杂的系统功能定制不方便，
但是 被CubeMx封装的接口做常规的功能设计已经足够了

这个就是标准化编程，生成代码的时候会把不是User Code的部分全部复盖掉，所以如果自己写代码一定要全部写在User Code的注释范围里面

推荐一看来是研究过啊