咳咳，如题，这是个题外话。
      事情源于我的++dan想法。移植下BLDC 6步换向的库，方便理代码结构。
% F! |7 @8 f) b& c6 B; Y' P      老实说有段时间没有摸32了，导致对HAL库不熟悉。所以拿到DEMO之后首先想到的是：移植一个呗，在自己的工程里跑起来。。。这，真是一个不嫌事儿多的孩子。。。
      好吧事实上看了六部换相的库之后我觉得移植库本身不是个正常人该做的事。
      一开始的想法 是，保留库完整性，继续使用基于HAL库的电机驱动库，然后自己的工程，使用STD库。
: u/ M# r! t' H+ p( g/ l      嗯，好像没什么毛病，电机库用HAL库，自己的代码使用STD库。。。（原谅我糟糕的编程基础）。
      于是，在耗费了一大堆时间，理清初始化和中断代码之后，移植好DEMO，遇到第一件难题。那就是，STD库和HAL库，不只是外设驱动不兼容，而是从系统头文件，寄存器宏定义开始就是不兼容的。这。。。这个之前还真没认真看。。。
      随之而来的现象就是。。。
: F! S  t! w: m9 s( o

      接着，尝试使用一对interface.c/h来隔离HAL库和STD库，视图规避因为电机库和测试代码引用造成 的重复定义问题。然而结果是行不通的，原谅我上学的时候编译原理没有好好学。

$ l/ G! |% Y1 k- E0 e3 O% P      接下来怎么办呢，再尝试将电机库编译成lib静态库，然后在新的工程里调用，看起来好像是个很好用的办法诶。
      好了，时间又过去半天，把电机库和驱动接口改好封装成lib，编译成功

      

      一阵窃喜，开始写测试DEMO，好了，包含lib，include xx.h。编译，链接，成。。。成，咋成这样了呀。。。

0 Z3 j" x* A+ v# t5 I+ H      原来是，生成lib静态库，规避了工程中不同文件之间重复定义的变量名、宏，但是不能规避函数重名的问题。接下来详细记录下收集到的信息。
# |! C8 a7 _% J( k2 S( l  X      首先，生成静态库的过程只是编译生成obj文件，静态库相当于一个obj文件集合，因此在工程中依然要和新的代码生成的obj文件一起，进行链接过程，这个过程中，链接器通过函数名对不同C文件之间的引用关系进行链接，这个时候就出现冲突了，静态库中有HAL库的系统时钟、中断一类的初始化操作，而新工程中STD库中也会有相同名字的函数。因此，链接映射不能唯一确定。
      到这里，不得不再次尴尬了。一开始偷懒的想法导致了这个丢脸的事情发生。
      今天还是留个记录在这里，希望大家能出点主意，分析下这个操作的合理性，以及还有没有可行的方案。
6 y4 w1 H- W$ x9 k8 K
# B$ i! U+ k, _5 v- f, V  Z6 s      现在的话，还想到几点可以尝试的（真是不死心。。。）
8 i: U+ d% m; F4 ^5 v1 `0 ^  N      1. 生成静态库之后，再写个小工具，一次性修改lib中的函数名，这样就能保证电机库的完整性。
      2.对静态库再进行一次封装编译生成新的静态库，网上大佬们说是不行的，因为静态库只是obj文件的集合，其中的函数名是不会因为封装编译了而改变。不过我想小小的改动下HAL库里面几个仅有的名字冲突的函数是个比较明智的办法。
      3.还有大佬提醒，静态库中不要封装单片机的中断服务函数，会无法响应。
         这个没有验证以及明白是什么原因，不知道是不是中断向量表的缘故。
2 g7 E8 V+ W+ D3 t$ I7 K* \, y; p
7 Y6 Z  X% \. y      其实这里花掉的时间用来熟悉HAL库应该也是差不多了，就权当给大家一个失败案例吧，噗。。。
+ {' z5 G" Q+ y) m7 c( }4 _      最后，大家一起来讨论下这个问题呗，我们就讨论可行性以及实施方案。
+ y: o+ p- a& `% |' q/ ~) G5 I5 Y

我觉得不应该进行两个库的融合。如果你只是想要BLDC的库，可以考虑用SPL替换原本的HAL库实现。

嗯，开始用SPL移植了，

现在都开始各种玩电机了。