Openmv多色识别

问题描述:最近把F1的芯片改成了F4,而今天晚上在重新调试openmv进行小车物料颜色识别时只能识别一次颜色。奇怪的是之前STM32F103ZET6用的程序框架与现在是一致的，换回之前的程序内容也识别不到第二个颜色（因为在openmv的程序内加了识别到什么颜色的物料就闪什么颜色的灯，所以可以看到一直在闪单色而没有调到下一个颜色）。

 

 

 

解决过程:首先我用其他好的程序片段进行了移植，但效果一样，于是我反复单步调试，发现卡在了颜色识别接受这里，对多个值检测后发现USART_RX_STA2错误（用的正点的串口中断代码，中断内接收出错，即没有识别到颜色），颜色值也是错误的0xFFFF FFFDA。

 

 

一 单步调试（记得选择硬件仿真）

 

 

二 调试后发现卡住的位置

首先在主函数中用 单步调试按钮2【之后的用简称】执行后发现是卡在了扫二维码这个函数，再用单步1进入后发现是USART_RX_STA2这条判断没有执行）

 然后我将值进行监测，发现得到的值是错误的

注意:在无法进入判断时可以先屏蔽判断，先执行里面的语句观察产生的改变

 这里观测到的值是0xFFFF FFFDA，但是串口接收到数据之后应该为物料颜色代码1 2 3中的一个，不符合条件而陷入死循环。（ps:图片是记录的视频中截图的有点模糊😳）

 

三 多次调试后回溯再分析

在多次单步执行后突然发现有一次刚好可以接收到正确数据，keil内颜色识别代码没有很大问题。

再到openmv写的代码中查看，发现实现颜色转换（表现就是闪下一个二维码代码颜色的灯）的并非keil内卡住的函数USART2_Process，而是openmv内number++到下一个颜色代码。

找到出问题的点在于keil与openmv接口处之后

【因为两边代码都分别单独用过，是好的，所以只可能是联动原因】

仅仅在USART_OUT()发送识别指令的前后加了500ms的延迟解决了问题。个人认为可能是M4芯片相比M3发送速度更快，而我设置的openmv波特率115200也比较高导致了频繁进入串口中断接收错误。

 

 

 

写在最后:解决方法感觉好简单，就是加了延迟，可是如果没有找到根本的原因就会卡在之前调试找出的函数处，而不会理清楚思路之后灵感迸发在串口发送指令的函数前后加个延迟就好了……以此为戒，理清楚 现象【没有识别第二个物料颜色→openmv闪单色光不变色】发生的原因比一顿乱造【移植又移植+单步调了又调】效率高得多。