用库函数传参 能否按位或

答案是看清况，而不是一股脑的写！（血泪的经验啊）

• 可行的情况：

//如gpio初始化结构体中的gpiopin参数
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_2;
//或是exti初始化结构体中EXTI_Lines参数
EXTI_InitStructure.EXTI_Line = EXTI_Line0 | EXTI_Line1;

由上图可知：这些可以用“按位与”的方式传参的都是一个二进制位表示一个特定名称的

• 不可行的情况

这里按位与会 死的很惨 不要问我怎么知道的（真的崩溃）GPIO_EXTILineConfig(GPIO_PortSourceGPIOB, GPIO_PinSource0 | GPIO_PinSource1);

来一探究竟

可见其中并不满足一个特定量占一位的原则，如GPIO_PinSource0与GPIO_PinSource1
0000 0000 如果与上  0000 0001 那么将得到0000 0001 
自然无法区分两个量

总结
在不知道能否按位与传参的时候要

1. 右击参数类型查看definition
2. 根据参数的位分配判断能否按位与传参

STM32库函数XXX_GetFlagStatus和XXX_GetITStatus的区别

只要涉及中断都会有这两个函数，那他们到底有什么区别呢？
先说结论：XXX_GetITStatus 是XXX_GetFlagStatus的增强版，它不仅仅检查硬件是否检测到了中断事件，还会检查系统是否允许处理这个中断(是否被设置为屏蔽)。

查手册的过程不放了，参考站内文章

关于为什么要有屏蔽位

可用于中断的使能与失能：在初始化外部中断时，通常需要设置中断屏蔽位来决定哪些中断线可以产生中断请求。

在调试或维护时：在调试或维护阶段，你可能需要临时禁用某些中断以排除故障或测试其他部分的功能。这时也可以通过修改EXTI_IMR寄存器来实现。

关于MDK导入文件后报错 Browse information of one files is not available

对于这个问题，更多的应该是忘记在魔法棒->c/c++那里设置文件夹路径，找不到文件。

但是我这里最后发现是因为缺少一个.h文件，OLEDfont.h(是字库文件)，在我把这个文件加上之后也就解决了问题。

用exti中断读取按键 忘记消抖 （更离谱的是，我忘记开启afio的时钟了 Damn!）

现象：没消抖时，按键就疯狂进中断。
解决办法：在进中断后加一点延时，再读取按键电平。 (经过测试10ms比较合适)
缺点：太耗时间，有卡顿现象。 推荐使用定时器读取按键，省去了延时消抖，不用占用主程序资源。

按键做软件消抖处理，是不是放在定时器中断里，非阻塞轮巡处理会更好！另外定时器开启后是不是就一直处于开启状态，不会占用MCU资源.
此外，刚反应过来这里的中断如同摆设，甚至还不如直接加在主程序中。 😢 😢😢

• 对于EXTI中断的方法
  适用于要读取按键按下次数的情景(因为可以设置为边沿触发，准确的读取按键按下的上升或下降电平)
• 对于定时器读取按键的方法：
  适用于判断按键是否按下，而不需要判断按的次数。（通过定时中断来读取电平来实现）

Damn！ 定时器中断里不要加Delay 抽象BUG一探究竟

问题：写了两个中断分别检测两个按键，一个是定时器中断，一个是EXTI中断(配置为高优先级)。两个按键不同时开启时没有任何问题。
但当我同时启用初始化两个按键，发现按下EXTI中断对应的按键程序就卡死了。 点击跳转中断函数体

困扰了一天，最后无意中看到江科大的讲解才点醒我问题在哪 定时中断不要delay–把时间控制的短一些_江科大

接下来是我顺藤摸瓜，先从delay函数出发，解决问题的过程。

delay函数

每次调用delay函数会进行初始化，而调用完会将用到的systick定时器给关闭 （关键点）

void delay_ms(u16 nms)
{		SysTick->LOAD = (u32)fac_ms * nms;//自动重装载值SysTick->VAL = 0x00;//清除计时器的值SysTick->CTRL |= (1 << 0);//SysTick使能，使能后LOAD寄存器的值就会被装载到VAL寄存器中，然后VAL开始向下递减while(!(SysTick->CTRL & (1 << 16)));//判断是否减到0，减到0时CTRL的第16位会置1，读取后会自动置0SysTick->CTRL &= ~(1 << 0);//关闭SysTick
}

1. 先单独分析定时中断中加Delay（左边的函数）

• 定时中断设置的每隔10毫秒触发一次中断 但是该死的定时器中断函数里Delay了15ms.
• 由下图可见，中断（触发）来的 比 中断函数执行完 还快。
  
  请注意`：这里虽然在定时器里用了delay，但是单独调用时却不会卡死或出bug。
  因为这里每一个新的中断之间是 相同优先级，是并列关系。 (这里是关键，先留个印象，后面就明白了)

加上右边的高优先级中断

1. 经过测试，在右边（EXTI）中断为高优先级的时候，且左边（定时）中断函数内无Delay时，也正常运行。
2. 但在右边（EXTI）中断还是高优先级的时候，左边定时中断加上Delay后。若触发EXTI中断，程序将卡死。
   

因为前面提到的定时中断，程序运行时可以说一直在delay，等待滴答定时器数到0。
而在等待的过程中，（EXTI）中断触发了，这是一个高优先级的中断，这里进行了中断嵌套(这里也是关键)

中断里进入了delay函数，正常执行后，退出时将systick(用于实现delay函数的定时器)关闭了，使得退出中断后在主程序的delay函数里卡死在while里（systick已经关闭了，不再向下记数）
//本来就在delay了，但是来一个高优先级的中断把原来的delay打断，执行完这个高优先级的中断函数中的delay后关闭了，但后面出来继续原来的程序发下delay不动了。

解决的办法

• 可以想见如果两个中断对时效性没有非常高的话，可以选择相同优先级进行配置，这样就不会出现中断嵌套 ，而delay复用而进入死循环了
• 或者呢可以修改delay函数，进行多次调用的优化。
  找到一篇博客有很好的解决方法做个准确的延时SysTick