不是加断点时出现的。 是因为出现问题了才加断点调试的。 我的理解是CAN的接收中断，打断了CAN的发送函数，此时可能hcan->Lock处于Lock状态。我的CAN接收中断函数的回调函数里又开启了下一次的中断接收，但是在HAL_CAN_Receive_IT()函数里，会判断hcan->Lock的状态，如果是Lock状态，直接就返回了HAL_BUSY.结果就是下一次的中断接收函数没有启动成功。 用的时候觉得传输挺快的，忘了CAN其实还是半双工，不可能同时发送和接收的。
在技术面前，没有尊卑贵溅，大卡小鸟，只有对与错！而犯错不用向谁道歉(但可向帮你纠错的人致谢以示礼貌)，向科技"道歉"即可(错了就改)！因为我们都是科技的学生，保不齐犯错！
取样是指连接ADC通道至内部保持电容的开关闭合， 闭合多久就是你问的“什么12.5个周期” 之后开关会断开， ADC通道的电压保持在内部电容， 之后就是从电容的电压转换成你要的12Bit数据（这就是你要问的转换时间） ADC通常是由程式控制它什么时候开始， 但它也可以由某一指定的计数器根据预设的时间让ADC开始转换， 这就是你问的由计数器触发ADC转换
本帖供楼主参考： https://www.stmcu.org.cn/module/forum/thread-614091-1-1.html
这个问题已经过去很久了。但我还是写一下答案吧。有机会自己写一篇。 在cmsis-rtos v1中是通过下面这个函数来转化优先级的： 翻译一下就是在freeRTOS中的优先级fpriority = tskIDLE_PRIORITY + priority - osPriorityIdlepriority的值是什么呐？在cmsis.os.c中有一段代码： 可以看出osPriorityNormal是0，可以看作一个基准。对于osPriorityNormal来说在freeRTOS的优先级是tskIDLE_PRIORITY - osPriorityIdle 那么在task.h中规定了它的值。比如stm32cubemx生成的f0的工程中默认取值是： 而osPriorityIdle在上面的取值是-3.所以可以看到实际上真正的几种实际上是osPriorityIdle（因为tskIDLE_PRIORITY + osPriorityIdle - osPriorityIdle = tskIDLE_PRIORITY）。 对于osPriorityNormal来说。这个取值在freeRTOS中的优先级是：tskIDLE_PRIORITY+3 而osPriorityIdle的优先级就是tskIDLE_PRIORITY 这样保证了freeRTOS和cmsis-RTOS的idle优先级的一致。 这一点在优先级较多的时候还行。但对于CM0那种可设置优先级只有4个的任务来说，害死人。（这一点还没有查看代码中有没有保险措施，但如果不加保护，优先级就会乱套。） 但freeRTOS的优先级还不是在真正的优先级。这部分可以查看一下其他人关于freeRTOS的描述。 下面是深入篇。如果你在调试的时候发现显示的优先级和自己设置的不同，不要奇怪。比如keil上面显示的是内核优先级。具体计算可以看下面说明。 另外对于M0内核和M3/M4内核的STM32产品内核优先级的计算是不同的。M0的内核优先级是8位中的高2位可配置。而M3和M4是高4位可配置。 这是core_cm0.h的代码（其中__NVIC_PRIO_BITS的宏定义是2）： 其中 这是core_cm4.h的代码（其中__NVIC_PRIO_BITS的宏定义是4）： m0的处理非常复杂，基本上最终的优先级是中断号和可配置中断的组合计算。 m4的简单一点，可以看出对于优先级不小于0的中断来说就是将优先级前移4位。 另外在F0的工程中发现没有configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY和configLIBRARY_LOWEST_INTERRUPT_PRIORITY的定义。在cubemx的配置中应该是无效的（但后者可以影响mx自动设置一些中断的优先级。还是要设置。）： 具体情况看能否找到官方文档再说。
结贴，原因找到了，是因为硬件上片选595的RCK使能引脚连接的有光耦，光耦导通频率低于我的主循环快跑刷新频率，所以当给程序中加上很大的延迟时候就可以正常工作，不加延迟快速运行，光耦速度达不到就出现乱码
明白楼主说的了，经验证的确如此。LL库的确坑多多，谨慎使用，推荐使用HAL库。 用HAL库就不存在此类问题了 的HAL库的IO初始化子函数中，做了IO输入判断，只有在输入模式下，才会有上下拉一说。 再次，在初始化IO结构体赋值前已经加了上下拉选项。
微信公众号
手机版
