全部学习汇总： GreyZhang/g_stm32f103: some hack for stm32f103 (github.com)
CubeIDE在使能FreeRTOS之后，会提示用户建议修改Tick的实现方式为TIM。我觉得这个很可能是因为TIM在精度上有着比SysTick更好的表现。修改之后，我尝试顺着工程代码看一下这个周期性的中断的实现。
配置完之后，main.c中会增加上面的这个接口函数。从配置的信息看，结合里面画出来的这个接口，很明显这就是Tick周期性中断处理的位置。这里的注释给的非常好，很有指导方向。接下来，顺着注释的解释我只需要去看看HAL_TIM_IRQHandler的调用处理即可。在进行这个之前，我可以现在这个回调函数中增加一个变量的处理，printf打印一下看看这个接口是否在一直调用。验证方式很简单，里面加一个计数器，然后在一个task中隔一段时间打印一下就好了。
这样，在这里增加了一个计数器，看看效果。如果这里被调用了，至少会有数值的增长变化。
在测试的任务中输出了一下这个数值，看得出来是在运行的。
接着，顺着代码进一步分析。这里找到了回调函数的调用位置，同时通过注释的提示，接下来的这个中断ISR的注册可能是在这个汇编代码里面。首先，先看一下整个工程里面这个接口的应用情况。
从工程的搜索情况看，其实这个接口的调用也在上面提到的汇编代码里面。而其他的地方都是头文件，最后的这三个映射处理，其实在代码中都没有继续处理的地方。如此，这个操作系统Tick的实现基本就找到了。
这个汇编文件中的内容包含了中断向量表的处理，在本文件中也提供了weak的定义方式。因此，在编译的时候即使是没有自定义编译也会通过，而自定义的代码实现后会取代执行。
前面看到的中断处理函数其实都是写成了很通用的接口，那么如何区分不同的TIM信号呢？从中断回调部分，其实有一个对象的判断。
那么，这个对象的注册处理又是如何实现的呢？